Re: Advice needed on howto take care about /usr/share/pyshared/scikits
On 31.03.2010 18:18, Yaroslav Halchenko wrote:
Dear Debianizers,
NB. I have asked similar question at debian-python [1] but had no
replies, so re-posting to -devel now
I am ITPing python-scikits-learn and possibly few other python-scikits-*
packages in the future. All of the packages would have 1 peculiarity,
they all would rely on having
$ cat /usr/share/pyshared/scikits/__init__.py
__import__('pkg_resources').declare_namespace(__name__)
As a resolution I am planing to package some silly Debian-native
(there is no per se the upstream for this single file) package
python-scikits-common
which would provide that base directory with __init__.py
This is a simple, robust way of packaging this file. You don't need to package
this as a separate source, usually it can be built as a separate binary from
some source which is common to all of these packages (as e.g. done in
zope.interface). Or include it in a package which is needed as a dependency of
all these python-scikits-* packages.
Am I missing possible other alternative (I think that unpleasant and evil
diverts, or inappropriate for this case alternatives aren't real choices
here, right)?
diversions only work if there is exactly one package diverting a file.
Alternatives are a possibility, but afaik not yet used for this purpose. It
would be nice if dpkg comes up with a declarative way of describing
alternatives. Other ways of providing/creating this file at installation time
should not be used.
Upstream is aware of the problem, http://python.org/dev/peps/pep-0382/, but
still lacks an implementation.
Matthias
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bb48ab8.8080...@debian.org
Re: Advice needed on howto take care about /usr/share/pyshared/scikits
Thank you Matthias! On Thu, 01 Apr 2010, Matthias Klose wrote: This is a simple, robust way of packaging this file. You don't need to package this as a separate source, usually it can be built as a separate binary from some source which is common to all of these packages (as e.g. done in zope.interface). Or include it in a package which is needed as a dependency of all these python-scikits-* packages. Well, there is no common package which would also be scikits-aware. Of cause I could request python-scipy maintainers to include it since scikits is kinda extensions to scipy... probably will do that ;) thanks again -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100401134350.gt8...@onerussian.com
Re: Advice needed on howto take care about /usr/share/pyshared/scikits
On Thu, 01 Apr 2010, Matthias Klose wrote: Upstream is aware of the problem, http://python.org/dev/peps/pep-0382/, but still lacks an implementation. Apparently (thanks to a reminder from Josselin) it seems I am fine shipping NO scikits/__init__.py at all ;) pysupport would take care about creating a blank one if necessary, and since all scikits/* installed from packages would be installed under the same path - explicit namespace declaration isn't necessary for them. IFF a user has some other scikits/* in his PYTHONPATH, then indeed he should take care about having magic __init__.py in those -- and then it seems to work fine again (according to my initial testing). Thanks once again! -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100401173818.gv8...@onerussian.com
