Re: Debian Python Policy [draft]
Looks fine to me. I'd prefer /usr/bin/python-X.Y, but that's cosmetics, not really important. -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Re: Debian Python Policy [draft]
On Mon, Sep 17, 2001 at 07:33:26PM -0700, Neil Schemenauer wrote: > 1.2. Module Path > > > Python searches a number of directories for modules. The module > search path for Debian has been ordered to include these locations at > the beginning of the path in the following order: > > /usr/local/lib/site-python > /usr/local/lib/python./site-packages > /usr/lib/python./site-packages I think this: /usr/local/lib/python./site-packages /usr/local/lib/site-python /usr/lib/python./site-packages should be the order. If I, for any reason, have more than two versions of coexisting Python interpreters, and have modules version-independent that works for two or more of them and one version-dependent module, I'd like to search before for version-dependent. I don't know how often this bizarre scenario occurs, but... And what happened to /usr/lib/site-python?
Re: Debian Python Policy [draft]
Mikael Hedin wrote: > Looks fine to me. I'd prefer /usr/bin/python-X.Y, but that's > cosmetics, not really important. It has been pythonX.Y for many years. We should not change it. Neil
Re: Debian Python Policy [draft]
Ricardo Javier Cardenes wrote: > I think this: > > /usr/local/lib/python./site-packages > /usr/local/lib/site-python > /usr/lib/python./site-packages > > should be the order. I see not problem with that. It shouldn't make any difference except in the case you describe. > And what happened to /usr/lib/site-python? Its been deprecated by the upstream distribution of Python. What would it be used for? Packaged modules must install themselves into /usr/lib/pythonX.Y/site-packages. Neil
Re: Debian Python Policy [draft]
On Mon, Sep 17, 2001 at 07:33:26PM -0700, Neil Schemenauer wrote: > I just want to ask a couple of questions to make sure that I understand this in detail. Suppose python2.1 is installed as python and you also have python1.5 installed. You have script poo which is invoked via #!/usr/bin/python and script bah which is invoked via #!/usr/bin/python1.5 > 1.2. Module Path > > > Python searches a number of directories for modules. The module > search path for Debian has been ordered to include these locations at > the beginning of the path in the following order: > > /usr/local/lib/site-python > /usr/local/lib/python./site-packages > /usr/lib/python./site-packages The debian search path for poo is (possibly in some other order, per later messages): /usr/local/lib/site-python /usr/local/lib/python2.1/site-packages /usr/lib/python2.1/site-packages ... and the debian search path for bah is: /usr/local/lib/site-python /usr/local/lib/python1.5/site-packages /usr/lib/python1.5/site-packages ... ? (that is, even in the 'python' package, versioned paths are used.) > > 4.1. Building Embedded Programs > --- > > Programs which embed a Python interpreter must declare a > `Build-Depends' on `python-dev'. > Versioning? If a package requires the dev for python1.5, will we be providing a python1.5-dev? Finally, what about package naming. Suppose I were maintaining python-popyda (which I happen to be). Suppose python (2.1) is released and it turns out that python-popyda is incompatible with it (I am not saying it is, I just want a concrete hypothetical). Should python-popyda be renamed to python1.5-popyda as soon as possible? Or should it remain as python-popy with a conflicts that prevents it from being used with python (2.1)? Suppose a later version comes out which is 2.1 available, but for some transition period, I want to provide both a 1.5 and a 2.1 compatible version. Should package names be python1.5-popyda and python-popyda? --- Again, I have some reservations about breakage on a mass scale when a new major of python comes out with this scheme, but I guess paranoid maintainers can take care of that by routinely making an equality depends in our packages. Jim Penny [EMAIL PROTECTED]
Re: Debian Python Policy [draft]
Jim Penny wrote: > I just want to ask a couple of questions to make sure that I understand > this in detail. Suppose python2.1 is installed as python and you > also have python1.5 installed. You have > script poo which is invoked via #!/usr/bin/python and > script bah which is invoked via #!/usr/bin/python1.5 > > > 1.2. Module Path > > > > > > Python searches a number of directories for modules. The module > > search path for Debian has been ordered to include these locations at > > the beginning of the path in the following order: > > > > /usr/local/lib/site-python > > /usr/local/lib/python./site-packages > > /usr/lib/python./site-packages > > The debian search path for poo is (possibly in some other order, per > later messages): > > /usr/local/lib/site-python > /usr/local/lib/python2.1/site-packages > /usr/lib/python2.1/site-packages > ... > > and the debian search path for bah is: > > /usr/local/lib/site-python > /usr/local/lib/python1.5/site-packages > /usr/lib/python1.5/site-packages > ... > > ? > > (that is, even in the 'python' package, versioned paths are used.) That's right. > > 4.1. Building Embedded Programs > > --- > > > > Programs which embed a Python interpreter must declare a > > `Build-Depends' on `python-dev'. > > > > Versioning? If a package requires the dev for python1.5, will we > be providing a python1.5-dev? Yes, I'll add that to the document. In general though packages should try to use the latest version of Python. Versioned packages (as in the version in the name) cause lots of pain and we should try to keep them to a minimum. > Finally, what about package naming. Suppose I were maintaining > python-popyda (which I happen to be). Suppose python (2.1) is released > and it turns out that python-popyda is incompatible with it (I am not > saying it is, I just want a concrete hypothetical). Should > python-popyda be renamed to python1.5-popyda as soon as possible? I don't think so. If there is only one popyda package then it should be called "python-popyda". It should depend on python-X.Y. Hopefully X.Y is the latest stable Python release. > Or should it remain as python-popy with a conflicts that prevents > it from being used with python (2.1)? Conflicts should not be necessary. > Suppose a later version comes out which is 2.1 available, but for > some transition period, I want to provide both a 1.5 and a 2.1 > compatible version. Should package names be python1.5-popyda and > python-popyda? In that case you should provide a python-1.5-popyda package. I'm hoping we can avoid doing that for most packages but the mechanism is there if we need it. > Again, I have some reservations about breakage on a mass scale > when a new major of python comes out with this scheme, but I guess > paranoid maintainers can take care of that by routinely making an > equality depends in our packages. The breakage should only happen once or twice in the Debian development cycle (i.e. when a new version of Python gets uploaded). Since extension modules depend on the major and minor version of Python that they are compiled against I see no way of eliminating the problem. When a new version of Python gets uploaded, a legacy version should probably get uploaded as well. For example, if the current "python" is 2.0 and the new "python" is 2.1 then "python-2.0" could be provided to ease the transition. The "python-2.0" package could be removed if there was no "python" version 2.0 in an official Debian release. Neil
