Re: python packaging infrastructure
Joe Wreschnig writes:
> On Fri, 2006-01-13 at 12:04 +0100, Matthias Klose wrote:
> > Joe Wreschnig writes:
> > > On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote:
> > > > - modules are installed into a directory not directly in sys.path.
> > >
> > > While I understand the rationale here, this could be *very* confusing
> > > for people coming to Debian from other operating systems.
> >
> > People will find their modules in the standard place after
> > installation, handle by a script in the postinst. The only place
> > where you do see the difference will be the output from some tools
> > like `dpkg -L' and `dlocate'.
>
> Indeed; what I meant was that we should make sure this is very
> well-documented, not just for the packagers, but for any Python
> developers who might be surprised as well.
>
> One issue that comes to my mind now is behavior with regards to
> dpkg-divert. I've diverted a number of Python modules on my system;
> under this centralized registry I would have to divert them for all
> versions at once (which is fine for me now, but maybe not everyone), or
> better, make python-whateveritscalled understand diversions of the
> target (per-version) module names.
By diverting the directory name which is not in sys.path, you could
divert all versions at once, diverting the directory in
/usr/lib/pythonX.Y you can divert them by version.
Ok, I think that something else, i.e. how to handle different versions
of a module. Looking at the benefits(?) of eggs ;). What about the
following setup: /usr/lib/pythonX.Y/dist-packages is added to
sys.path, python policy requires to install distribution packages into
this place, maybe supported by a distutils patch adding a new option
to setup.py. when you do build your own modules these are installed
into /usr/lib/pythonX.Y/site-packages. By changing the order of the
two directories you can priorize your locally installed modules. (yes,
we do have the /usr/local/lib/pythonX.Y/site-packages directory as
well, but making this the default would break the existing packaging).
> > > Is this really feasible? The installed size will be, rough, source size
> > > * (the number of Python versions you have installed + 1), then * 2 if
> > > you have pyo files as well, since we're compiling for multiple versions.
> > > Since the installed size would vary based on the number of Python
> > > versions you have installed, an accurate report via APT would be
> > > impossible.
> >
> > dpkg does have support for the installed size, you could do that;
> > unless it's not done by some helper script nobody will use it anyway ;)
>
> Yes, but afaik Installed-Size is mostly used by APT to gauge disk space
> deltas when upgrading. Since it wouldn't know until the package was
> unpacked (and how many copies of the modules needed to be compiled were
> figured), this would prevent the most common case from working no matter
> what. It also wouldn't know that installing a new Python version would
> cause a lot of disk space usage as all the new modules were recompiled.
> So I think it's best not to guess at all, and at least be consistently
> inaccurate.
ok, agreed, we could just have a minimum size, which might be more
accurate what we have now, but not the exact size.
Matthias
Reply to: