Re: Proposal: Reorganizing Python for Python 2.0
It sounds good to me. I think the admin should have the option of setting the symlinks to default to 1.5 or 2.0. -D On Tue, Jan 09, 2001 at 03:04:33PM +0100, J?r?me Marant wrote: | [snip proposal for multiple version installation] | -- | Jérôme Marant <[EMAIL PROTECTED]>
Re: Proposal: Reorganizing Python for Python 2.0
I thought that's what you meant with the executable. I was imagining that the python executables would be in separate directories (or just different names) ie /usr/bin/python15 and /usr/bin/python20. Then have a symlink /usr/bin/python -> /usr/bin/python20. If you have a different solution that's fine as well. -D On Tue, Jan 09, 2001 at 06:31:31PM +0100, J?r?me Marant wrote: | D-Man <[EMAIL PROTECTED]> writes: | | > It sounds good to me. I think the admin should have the option of | > setting the symlinks to default to 1.5 or 2.0. | | Sorry, I can't see what symlink you are dealing with ? | | -- | Jérôme Marant <[EMAIL PROTECTED]> | | http://jerome.marant.free.fr |
Re: Proposal: Reorganizing Python for Python 2.0
On Wed, Jan 10, 2001 at 08:53:39AM +0100, J?r?me Marant wrote: | D-Man <[EMAIL PROTECTED]> writes: | | > If you have a different solution that's fine as well. | | The whole stuff is handled by alternatives. | See update-alternatives manpage. | Oh, ok. Another part of the Debian package system I haven't learned yet. (I have only had Debian installed for a few days now) It's another reason Debian is better than RH. :-) -D | It would be better to have a small script that: | - update-alternatives | - run compileall.py in /usr/lib/python/site-packages | | And that's all. | | Cheers, | | -- | Jérôme Marant <[EMAIL PROTECTED]> | | http://jerome.marant.free.fr | | | -- | To UNSUBSCRIBE, email to [EMAIL PROTECTED] | with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] |
Re: Proposal: Reorganizing Python for Python2 (and fixes for the previous proposal)
On Wed, Jan 10, 2001 at 09:16:51AM -0600, Rob Tillotson wrote: | [EMAIL PROTECTED] (Jérôme Marant) writes: | > And thanks to a small change in the interpreter, the current version | > looks for modules in /usr/lib/python//site-packages and | > then /usr/lib/python/site-package. Other modules are invisible. | | Note that there is no change to the interpreter necessary to achieve | this. Debian Python installations already search in both | /usr/lib/python/site-packages and /usr/lib/site-python for packages. | | I would like to make a counterproposal regarding how to handle the | issue of compiling .pycs for multiple versions: | Are .pyc's incompatible across versions or did the bytecode spec remain the same? In any case, I would expect the 2.0 interpreter to be able to read 1.5.2 bytecode. If the modules are compatible with different versions, then it must not use any new features not found in all versions. What I'm getting at is the 1.5 interpreter could be used to byte-compile the source and then both interpreters use the 1.5-generated bytecode. (Does anyone know where the bytecode format is documented? I am interested in understanding how bytecode works and is designed.) -D
Re: Proposal: Reorganizing Python for Python 2.0
On Wed, Jan 10, 2001 at 12:32:02PM -0800, Neil Schemenauer wrote: | On Wed, Jan 10, 2001 at 11:01:40PM +0100, [EMAIL PROTECTED] wrote: | > What I want is if we allow both Python 1.5 _and_ Python 2.0 to be | > So we need | > ... | | No, we don't. Python already installs its modules into | | $PREFIX/lib/python$VERSION | | I've already built a Python 2.0 package with installs along side | of the regular Debian Python package. No problem. | | Neil | Oh, please share it with us! :-) -D
Re: Our application doesn't work with Debian packaged Python
On Tue, Jan 16, 2001 at 11:44:48AM +0200, Danie Roux wrote:
[snip]
|
| I then went and look at the source rpm. They have this patch in there:
|
| --- Python-1.5.2/Python/importdl.c.global Sat Jul 17 16:52:26 1999
| +++ Python-1.5.2/Python/importdl.cSat Jul 17 16:53:19 1999
| @@ -441,13 +441,13 @@
| #ifdef RTLD_NOW
| /* RTLD_NOW: resolve externals now
| (i.e. core dump now if some are missing) */
| - void *handle = dlopen(pathname, RTLD_NOW);
| + void *handle = dlopen(pathname, RTLD_NOW | RTLD_GLOBAL);
| #else
| void *handle;
| if (Py_VerboseFlag)
| printf("dlopen(\"%s\", %d);\n", pathname,
| -RTLD_LAZY);
| - handle = dlopen(pathname, RTLD_LAZY);
| +RTLD_LAZY | RTLD_GLOBAL);
| + handle = dlopen(pathname, RTLD_LAZY | RTLD_GLOBAL);
| #endif /* RTLD_NOW */
| if (handle == NULL) {
| PyErr_SetString(PyExc_ImportError, dlerror());
|
The only difference here is the addtion (via bitwise or-ing) of the
RTLD_GLOBAL flag. Check with some documentation and see what
RTLD_GLOBAL flag means and how it affects the dlopen functions. I
imagine this function is a part of glibc. Can anyone else help here?
-D
Re: RFC: python-base, debconf and py/pyc files
I think this sounds good. Then users who don't want to use the extra disk space don't have to. There is another tradeoff though. I compared the size of several .py and the corresponding .pyc files from the standard library and noticed that the .pyc file is a little bit larger. If the user likes disk space more than speed they might want to have only .py files on the system and let the interpreter recompile the source everytime it is used. -D On Fri, Mar 23, 2001 at 09:39:07PM +0100, Gregor Hoffleit wrote: | Hi, | | currently, our Python packages mostly ship .py files and compile them into | .pyc files at run time in order to save space in the debs. | | There's no reason, though, to keep the .py files on machines that only | deploy software[1] | | I wonder if I should debconf-ify python-base and add an debconf option that | sets a system-wide policy about how to deal with .py/.pyc files. That could | be one of: | | * install both .py and .pyc files | * install only .pyc files | * install only .py files | | The postinst scripts of the various python packages would then enforce this | policy according to the global debconf option. Packages could also provide | private debconf options to override this. | | Any comments ? | | Gregor
Re: Python 2.1 out
On Wed, Apr 18, 2001 at 10:25:52PM +0200, Florian Weimer wrote: | Steve Purcell <[EMAIL PROTECTED]> writes: | | > Licenses aside, there are the same technical issues with Python 2.1 | > as with Python 2.0. | | Python 2.1 seems to print some diagnostic messages during run-time; | this might affect scripts which are invoked in cron jobs. Are you sure they aren't warnings regarding code that will not work as expected in future versions? -D
Re: Python 2.1 out
On Thu, Apr 19, 2001 at 12:17:40PM +0200, Florian Weimer wrote: | Gregor Hoffleit <[EMAIL PROTECTED]> writes: | | [Python warning messages] | | > Could you mail an example of such a message ? | | y = None | def fun(): | y = None | def bar(): | y | bar() | | fun() | | results in: | | :2: SyntaxWarning: local name 'y' in 'fun' shadows use of 'y' as global in nested scope 'bar' | def fun(): Yeah, that code will almost certainly break in 2.2 when nested scopes become mandatory. It may have been intended, but assignment to a local variable overshadowing a global is rarely the intended effect. Anyways, if you want to get rid of those message now, without changing the code use the -W option to the interpreter. Example : $ python -W ignore Scope.py (I created a file called Scope.py with that code in it) See the last paragraph at http://www.python.org/doc/current/lib/warning-filter.html -D
Re: Status report on python2 transition
On Thu, Jul 05, 2001 at 06:43:08PM +0100, Aquarius wrote: | In article <[EMAIL PROTECTED]> you wrote: | > I just browsed /usr/bin and /usr/sbin, and indeed there are plenty of | > scripts that use "#!/usr/bin/env python". If we consider the possibility | > that somebody installs non-compatible Python versions in the path, then | > these are bugs in that packages. Thanks for pointing this out! | > | > I guess we really, really need a Debian Python policy that mentions all | > these things. | | Especially since "#!/usr/bin/env python" is recommended in the Python | FAQ (section 4.63 -- | http://www.python.org/cgi-bin/faqw.py?req=show&file=faq04.063.htp). Is | it bad to use in general, or just bad to use on Debian systems? It is bad only when you wanted to use a different version of python than the one that is first in the PATH (which is what /usr/bin/env will tell you when you ask for 'python'). The whole discussion here is how to simultaneously deal with different, potentially incompatible or known to be incompatible, versions. I don't have any real solutions. Maybe as a reference it would be a good idea to mention what I have done for Java on my cygwin (win2k) box at work : I have jdk 1.1.8, jdk 1.2.2, and jdk 1.3.0 installed into various directories. As is common with windows and java everything for that version lies under that base directory (ie d:\jdk1.1.8). I have some shell scripts in my path called 'java1' 'java2' and 'java3'. I have a symlink from 'java' to the version I want to be the default. Then I can pick which JVM to run the java code by simply switching the command slightly. The shell scripts set the JAVA_HOME environment variable to match the selected JVM. I also added a command line switch, --classpath, that _appends_ the jar files to the existing classpath (which would include commonly used libraries such as swing or 3rd party libs used by our product). Maybe that will help someone devise a plan (policy) for Python on Debian. If you want those shell scripts, I am more than happy to provide them. They are really simplistic hacks, though. -D
Re: jython
On Fri, Jul 13, 2001 at 11:44:33AM +0200, Radovan Garabik wrote: | To add to the multiple python versions confusion: | jython recently appeared in debian. | To make things correctly, it should be possible to | use it as replacement of python, and also it should be | possible to have both python and jython installed | simultaneously. | | and, of course, C modules and many pure python scripts do | _not_ work with jython, so alternatives are out of question. | (well, since nobody with a sense of reality would want | to use jython as a replacement of python, not having | it available as an alterantive of python is not such a big problem) And, of course, many programs that are written with the intent of being used with Jython probably use Java classes or Swing which obviously don't work with CPython. Most pure python scripts/programs should work as long as they don't depend on a) C extensions, b) os module specific stuff (much of that is inaccessible from Java), and c) depend on implementation-specific details that are not specified in the Ref Man. -D
Re: Status report on python2 transition (possible solution)
Last night I had an idea for organizing multiple python versions in Debian. o all core (the interpreter) python packages will be versioned ex python-1.5.2 python-2.0 python-2.1.1 Each of these will contain /usr/bin/pythonX.Y.Z and "provide" 'python'. /usr/bin/python will refer to the newest version, or could use the alternatives technique to let the admin select a default version. This is for non-Debian specific scripts that use the traditional #!/usr/bin/env python, or for quick (non-Debian specific) scripts that don't care what version they run on. It is also useful to simply run "python" to get an interactive prompt. o all other packages will have a versioned depends on the lowest version it runs with, also a max version if it exists o The #! line should look something like #!/usr/bin/deb_py_ver 1.5.2 - for a program that works with python 1.5.2 and up. If a program works with only 1.5.2 and 2.0 it would look like #!/usr/bin/deb_py_ver 1.5.2 2.0 o /usr/bin/deb_py_ver will be a script/program that takes 2 arguments, a min version and a max version of python that can be used to run this script. It will have a database of the installed python versions and it will find the newest version that fits within the requested range to run the script with. A '-' can be substituted for a version to denote "any" or "no limit" in that direction (either min or max). Rationale : Python is smart -- it knows where to find itself (ie libpython) and the standard library. Unlike java it doesn't need to be told. This keeps scripts simple and allows them to work with multiple versions of python. The #! line is Debian-specific, but it is simple for a maintainer to have a patch for that one line. Disk space is cheap nowadays (I saw a disk in an add that was $3/GB). Having a duplicate of .py/.pyc files isn't a major issue. Most people will only have 1 version anyways and don't need the extra complexity trying to minimize the disk usage with multiple versions. Python developers are not "most users". They will, almost certainly, have multiple versions that they will want to manage themselves for testing purposes (such as new development on the interpreter). These will be in their home directory or /usr/local and not affect the rest of the package system. Python app developers can have mulitple pythons installed and use a "wrapper" script to get a particular version. For example main.py main-1.5.2.py main-2.0.py main.py will have the "real" 'main'. main-1.5.2.py will have #!/usr/bin/deb_py_ver 1.5.2 1.5.2 execfile main.py thus is ensures that it will be run by 1.5.2 and has no duplication of code. It could just as easily have #!/usr/bin/python1.5.2 as the first line. main-2.0.py follows the same pattern. This is just an idea I had, and I am almost certain that I am overlooking some issue. Consider this, and (maybe) use it in building an optimum solution :-). -D PS. Thanks Gregor and all for your effort in providing the python packages.
Re: Status report on python2 transition (possible solution)
On Fri, Jul 13, 2001 at 11:30:28PM +0200, Carel Fellinger wrote: | On Fri, Jul 13, 2001 at 03:25:20PM -0400, D-Man wrote: | ... | > o The #! line should look something like | > #!/usr/bin/deb_py_ver 1.5.2 - | | I can't get things like this to work. It seems one parameter at | most is allowed there. Huh? The idea was that there would be a script/program named deb_py_ver. It would take 2 command-line arguments and determine which python binary should be used. It would then exec that python on the script (which, IIRC, is on stdin of deb_py_ver). This would allow having a single program, rather than an exponentially growing number of symlinks. Otherwise the symlink idea is the simplest implementation, except for handling which package to put each link in. -D
Re: Status report on python2 transition (possible solution)
On Fri, Jul 13, 2001 at 06:27:20PM -0400, David M. Cooke wrote: | At some point, D-Man <[EMAIL PROTECTED]> wrote: | > On Fri, Jul 13, 2001 at 11:30:28PM +0200, Carel Fellinger wrote: | > | On Fri, Jul 13, 2001 at 03:25:20PM -0400, D-Man wrote: | > | ... | > | > o The #! line should look something like | > | > #!/usr/bin/deb_py_ver 1.5.2 - | > | | > | I can't get things like this to work. It seems one parameter at | > | most is allowed there. | > | > Huh? The idea was that there would be a script/program named | > deb_py_ver. It would take 2 command-line arguments and determine | > which python binary should be used. It would then exec that python on | > the script (which, IIRC, is on stdin of deb_py_ver). This would allow | > having a single program, rather than an exponentially growing number | > of symlinks. Otherwise the symlink idea is the simplest | > implementation, except for handling which package to put each link in. | | That's not the problem -- the problem is that the command specified in | the #! is passed the rest of the line as _one_ argument (at least on | Linux). That's why you can't do, for instance, | | #!/usr/bin/env python -O | | as the first line. I thought that would work, which is why I was confused :-). | I suppose you could split the argument on spaces -- although I'm not sure if | other Unices (the Hurd, anyone?) pass the rest of the line or just the first | argument. | | Another alternative would be | | #!/usr/bin/deb_py_ver 1.5.2- | | and | | #!/usr/bin/deb_py_ver 1.5.2-2.1.1 | | That's one argument. Ok, sure, replace the space separator between the versions with a different ASCII separator. -D
Re: Status report on python2 transition (possible solution)
On Sat, Jul 14, 2001 at 11:27:55AM +1200, Carey Evans wrote: | D-Man <[EMAIL PROTECTED]> writes: | | > o all core (the interpreter) python packages will be versioned | > ex | > python-1.5.2 | > python-2.0 | > python-2.1.1 | > | > Each of these will contain /usr/bin/pythonX.Y.Z and "provide" | > 'python'. | | It might be more convenient to have a separate package called | 'python'. This could depend on the latest Python to make "apt-get | dist-upgrade" work, and conflict with any old packages that are a | problem (like the current python-base). It might be more convenient, unless a user, for some strange reason, wants to only have an older version of python. | It would also provide the /usr/bin/python symlink, if it doesn't get | managed by alternatives. Since the "python" command will be for users, | should the sysadmin really get to choose an older version for them? Why shouldn't the sysadmin get to choose? Suppose a new python is released, but the admin is afraid that his scripts (suppose they use 'python' too) might not work with it. He might want the default python to stay the same (the now "old" version) while installing the new one to start migrating to. | (See the gcc, gcc-2.95 and gcc-3.0 packages, where /usr/bin/gcc is a | symlink to /usr/bin/gcc-2.95; except on hppa which uses gcc 3.0.) Are you saying that gcc 2.95 and 3.0 can peacefully co-exist on a system? That would be good news to me :-). | BTW, I would suggest "python-2.1" instead; 2.1.1 is only a bug-fix | release, even if the license is one of the bugs, and 2.1.2 will be the | same if it's ever released. Ok, if that is the naming convention that is preferred. | > o all other packages will have a versioned depends on the lowest | > version it runs with, also a max version if it exists | | I wouldn't like to try to be clairvoyant if I was packaging a Python Sure, but also consider older packages. For example, we are now moving to 2.0 (or 2.1) for the "default" python. We still want to provide 1.5.2 versions of all the other packages, so they should (now) specify that they don't work with >= 2.0 because we know that now. | script; how about just depending on the latest version in the archive | that it works with. One of the problems at the moment is that almost | all packages using Python optimistically depend on >= 1.5.2. Either it is optimistic, or there was no known conflict with a newer version (because it didn't exist ;-)) when it was built. | Just have them depend on "python-1.5.2" or "python-2.1". Ok. So we have a version of each extension package to match with each version of python currently supported. I have no problem with that. | > o /usr/bin/deb_py_ver will be a script/program that takes 2 | > arguments, a min version and a max version of python that can be | > used to run this script. | | Can I suggest that with only a few weeks until Python freezes, | anything like this is left until the following Debian release? That | will give us several months to iron out any bugs in the script, and in | the packages using it, before time runs out. Well, I have no fancy title (like "Debian Maintainer") so I really have no authority on the matter. The idea just came to me and it seemed pretty good so I thought I'd share it :-). You can do what you like with the idea. -D
Re: Status report on python2 transition (possible solution)
On Sat, Jul 14, 2001 at 01:30:17AM +0200, Carel Fellinger wrote: | On Fri, Jul 13, 2001 at 07:05:17PM -0400, D-Man wrote: | ... | > Ok, sure, replace the space separator between the versions with a | > different ASCII separator. | | Won't do either, as this would make it impossible to pass default | options like: ^ Yeah, but you're already still limited to only 1 option. | |#!/usr/bin/python -u | | I know, this also doesn't work with | | #!/usr/bin/env python -u | | and that's why I don't like that idiom (or actually I don't like this | restriction in linux:) I like the idiom because you don't necessarily know where python is. Now that I've learned of the restriction on arguments, I don't like that either :-). Say, ..., is there a way for a python script to find out where the python binary executing it is? If so, then the "real" script could be run via os.system by the Debian script that uses #! deb_py_ver. -D
Re: Status report on python2 transition (possible solution)
On Sat, Jul 14, 2001 at 01:07:21PM +1200, Carey Evans wrote: | D-Man <[EMAIL PROTECTED]> writes: | > Sure, but also consider older packages. For example, we are now | > moving to 2.0 (or 2.1) for the "default" python. We still want to | > provide 1.5.2 versions of all the other packages, so they should (now) | > specify that they don't work with >= 2.0 because we know that now. | | However, that can lead to packages breaking when a new version of | Python is installed, without pulling in the newer extension modules | and packages that use the new scope rules properly, and have variables | named "yield" and "div" renamed to something else, etc. Yes. Maybe each extension should just depend on a single version of python and need to be rebuilt for each new python release. | dpkg and apt provide very good dependency checking, so we should try | to use it. Definitely. | Anyway, *do* we actually need all the extension modules for Python | 1.5.2? For Debian itself, there's Zope and Mailman, but they don't | depend on any other Python packages. reportbug uses python-newt, but | it should be changed once python-2.1 is available, so that Python | 1.5.2 isn't installed by default on new Debian 3.0 installations. | | Are there any other reasons to provide all the modules for Python | 1.5.2 (now more than two years old) in Debian 3.0? Who knows what people might be using that isn't packaged for Debian. | > Well, I have no fancy title (like "Debian Maintainer") so I really | > have no authority on the matter. The idea just came to me and it | > seemed pretty good so I thought I'd share it :-). You can do what you | > like with the idea. | | I probably shouldn't be using my @debian.org address for this Oh, I hadn't even paid any attention to that ;-). | discussion anyway; I've done one package upload in the last six | months, which hardly makes me an active Debian maintainer or any kind | of authority. ;-). | I'm not really talking just to you, but generally; by all means keep | coming up with ideas to improve the Debian Python packages, but please | don't keep Python 2.1 out of Debian 3.0! I agree! -D
Re: Status report on python2 transition (possible solution)
On Sat, Jul 14, 2001 at 04:05:56PM +1200, Carey Evans wrote: | D-Man <[EMAIL PROTECTED]> writes: | | > Yes. Maybe each extension should just depend on a single version of | > python and need to be rebuilt for each new python release. | | It makes things considerably simpler, from my point of view. | | Then, of course, we need unique package names for each package. Yeah | Something like "python-imaging-python1.5", "python-imaging-python2.0" | and "python-imaging-2.1"? Aagh. Since we have "python1.5" and "python2.1", how about "python1.5-imaging" and "python2.1-imaging". Then if the maintainer wants to include a version on the package it could be (I don't know PIL's version) "python2.1-imaging2.3". I don't think that is too ugly. | (Picking on python-imaging because it contains binary modules, so it's | version specific anyway.) | | > | Are there any other reasons to provide all the modules for Python | > | 1.5.2 (now more than two years old) in Debian 3.0? | > | > Who knows what people might be using that isn't packaged for Debian. | | True. I feel that we can't keep everyone happy forever, and Python | 1.5 has to go away someday; OTOH, I'm running quite up to date | unstable, so maybe I don't have the same perspective as many users. ;) I agree with both of those, though I think that at least one "old" version should be kept. I don't think 1.5.2 needs to disappear quite yet because it is the most common version (in a lot of diff. environments). It could probably go in the next (after woody) release because by then 2.x will have filled it place as the most commonly used. -D
