Re: dh_python2: pyinstall files
[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
Reply to: