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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
