[Barry Warsaw, 2010-11-22] > Is this because flaskext/ isn't actually a (Python) package that exists in the > python-flask source?
Yes, Flask's extensions are shipped under flaskext namespace. To avoid Conflicts between python-flaskext.* packages, I will provide this namespace in python-flask package - packages with Flask extensions (will) Depend on python-flask (or Enhance it) anyway. > If so, in this specific case, why not just add a directory called flaskext and > an empty flaskext/__init__.py to the source code (via a patch if not > upstream)? Then it would just be a matter of adding 'flaskext' to the > setup.py `packages` key. That's one of the ways to handle it, yes. I just think it's easier to create debian/python-flask.pyinstall file than to patch setup.py (which can change from time to time). It will also require much less typing if a file should be installed for specific Python versions only or when you want to replace python2.5's file only. anyway, this feature is not meant to replace distutils - it extends it and provides a really easy way to install files for source packages that lack setup.py files. Just like pkg.install files provide an easy way to install files when Makefile is missing. > I started looking at using debian/pkg.install to handle a case that Scott > mentioned to me w.r.t. the flufl.* packages. Because flufl is a namespace > package, we were worried about how to handle the flufl/__init__.py file. > Scott's suggestion was to create two binary packages in the flufl.i18n source > package, the latter owning only flufl/__init__.py. I started to go down this > path but realized, 1) it's actually kind of painful because it was difficult > to figure out the build paths to create the file in; 2) it was unnecessary > since AFAICT, dh_python2 handles namespace packages for you. dh_python2 doesn't create __init__.py files, that's python-support (and to be honest, I don't like this feature, see bug I reported to see why) You should create separate binary python-flufl package that provides flufl/__init__.py file and depend on it in two other packages, yes. BTW: how about creating new pynamespaces package and provide binary packages there. Developers could report bugs against it (asking to create new binary python-foo package that will provide foo/__init__.py file). We can ask FTP masters to make this package special (since it will provide empty files only) and fast track it. It should be used only if there's no other sane source package that can provide additional binary package of course (or one of existing ones cannot be used) > >foo/bar.py spam > >=============== > >cp foo/bar.py debian/pkg/usr/lib/python2.6/site-packages/spam/ s/2.6/2.5/ > >cp foo/bar.py debian/pkg/usr/lib/python2.6/dist-packages/spam/ > >cp foo/bar.py debian/pkg/usr/lib/python2.7/dist-packages/spam/ > I think this is pretty cool. I'd like to also see a syntax for path > exclusion, so for example I could handle the namespace package case above > (though I understand in dh_python2 that's not necessary). E.g. > > flufl -flufl/enum 2.6- well, glog.glob is used to parse pattern, so you can use something line "flufl/[!e]*/*", but you're right - I will add pkg.pyremove files to remove already installed files (I want to keep pyinstall's syntax simple). It will also be useful to remove __init__.py files (when upstream forgot to set the namespace_packages in setup.py and Debian maintainer wants to avoid patching it) > I want to get back to my test+refactor branch > anyway; I've been distracted on other things lately. I will merge your branch before uploading to experimental (IIRC, you already have commit rights, though) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101122231341.gc30...@piotro.eu
