Re: [Help] Failed to apply new Python policy to GNUmed packages
> > That is, you're now shipping some modules in a private location > > This is what I understood as recommendation in #516037. Well, you are trying to solve two things at once: 1) make the "python -m" calling convention work 2) move GNUmed modules to a private location While, yes, this WAS recommended in that report I tried furiously to argue against doing both at once because only the first is needed to deal with the actual bug raised. While it is tempting to "slip in" not strictly needed improvements into a bugfix it is usually - as is quite evident here - a road down which dragons live. Don't. Karsten -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Help] Failed to apply new Python policy to GNUmed packages
For what it's worth here is my concluding suggestion in that bug thread: - My suggestion would be: - call gnumed.py with the python -m ... option if that works - this would rid us of that hardcoded path - a great thing - leave modules where they are and GNUmed finds them by default - if the Debian package maintainers want to put packages elsewhere, fine, as long as the rest of the code finds them by default - I am just adverse to including more detection logic for no good reason that I can see - If that had been followed no problem would have come up. The whole problem has ONLY been created by *additionally* moving the Python files to a private location. Now, I am surely fine with moving them there -- but as the old adage goes one needs to walk before one can attempt to run. Now, again, if you are hell-bent on doing both -- simply adjust PYTHONPATH in /usr/bin/gnumed as suggested by 0.4.2 upstream. Karsten -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Help] Failed to apply new Python policy to GNUmed packages
Hiya, Andreas Tille wrote: > On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote: > >> That is, you're now shipping some modules in a private location > > This is what I understood as recommendation in #516037. Yes, that's recommended, but it's not a requirement. Anyway, you almost got it! >> (usr/share is >> not in PYTHONPATH), so they are not found when you try to import them. >> >> You could ship Gnumed in /usr/share/gnumed/Gnumed and append >> /usr/share/gnumed >> to PYTHONPATH in /usr/bin/gnumed (that seems to work fine here, > > I tried to implement your suggestion (see last commit in SVN) but it > does not work for me. You're missing a 'export' before setting the variable (or call python in the same line you set it). > I really wonder how this new python-support stuff > really works. It installs *.pyc files in the same location as the > *.py files - how can this work for different Python versions? Because different versions don't break the syntax (at least AFAIK), so if your program works with Python 2.4, it will work with 2.5 and 2.6 too. That's not the case with Python 3 though. You don't need to install it for every supported Python version, that's only done by public modules and extensions. > In the first releases of gnumed-client package I used Gnumed.pth but > dropped this since I used python-support (version 0.3.x). Does this > mean I might use this again? You don't need it, you can remove it (I've seen you've added it back). Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: [Help] Failed to apply new Python policy to GNUmed packages
> >> That is, you're now shipping some modules in a private location > > > > This is what I understood as recommendation in #516037. > > Yes, that's recommended, but it's not a requirement. > > Anyway, you almost got it! > > >> (usr/share is > >> not in PYTHONPATH), so they are not found when you try to import them. > >> > >> You could ship Gnumed in /usr/share/gnumed/Gnumed and append > >> /usr/share/gnumed > >> to PYTHONPATH in /usr/bin/gnumed (that seems to work fine here, > > > > I tried to implement your suggestion (see last commit in SVN) but it > > does not work for me. > > You're missing a 'export' before setting the variable (or call python in > the > same line you set it). Ah, thanks. Emilio, you are clearly a better expert on packaging Python code under Debian than me :-) > > I really wonder how this new python-support stuff > > really works. It installs *.pyc files in the same location as the > > *.py files - how can this work for different Python versions? > > Because different versions don't break the syntax (at least AFAIK), so if > your > program works with Python 2.4, it will work with 2.5 and 2.6 too. I believe Andreas was wondering about the pre-compiled pyc files being installed alongside the py files. If they are stored there they can only be precompiled by one particular Python version at a time. This made us wonder what, for example, happens if user A runs GNUmed with Python 2.5 at the same time that user B runs GNUmed with Python 2.6 on the same machine... > You don't need it, you can remove it (I've seen you've added it back). That was one of my ill-fated suggestions - it would have worked but it is clearly better if things work without it. Karsten -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Help] Failed to apply new Python policy to GNUmed packages
Karsten Hilbert wrote: >> You're missing a 'export' before setting the variable (or call python in >> the >> same line you set it). > > Ah, thanks. Emilio, you are clearly a better expert on > packaging Python code under Debian than me :-) That was shell ;) >>> I really wonder how this new python-support stuff >>> really works. It installs *.pyc files in the same location as the >>> *.py files - how can this work for different Python versions? >> Because different versions don't break the syntax (at least AFAIK), so if >> your >> program works with Python 2.4, it will work with 2.5 and 2.6 too. > > I believe Andreas was wondering about the pre-compiled pyc files being > installed alongside the py files. If they are stored there they can > only be precompiled by one particular Python version at a time. This made > us wonder what, for example, happens if user A runs GNUmed with Python > 2.5 at the same time that user B runs GNUmed with Python 2.6 on the same > machine... In that case the .pyc files won't be loaded, but the .py ones, I guess (please somebody correct me if I'm wrong). Nothing to worry about as people will usually be using the default interpreter. >> You don't need it, you can remove it (I've seen you've added it back). > That was one of my ill-fated suggestions - it would have worked but it > is clearly better if things work without it. That would defeat the purpose of placing the modules in a private location, so yes, better to remove it :) Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: [Help] Failed to apply new Python policy to GNUmed packages
On Sun, 29 Mar 2009, Karsten Hilbert wrote: Well, you are trying to solve two things at once: 1) make the "python -m" calling convention work 2) move GNUmed modules to a private location While, yes, this WAS recommended in that report I tried furiously to argue against doing both at once because only the first is needed to deal with the actual bug raised. While it is tempting to "slip in" not strictly needed improvements into a bugfix it is usually - as is quite evident here - a road down which dragons live. Don't. Well, I didn't in the first place (look at 0.3.12 package). But since 0.4.x it stopped working this way - so I tried to apply the recommendations of the updated Python policy from scratch. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Help] Failed to apply new Python policy to GNUmed packages
On Sun, 29 Mar 2009, Karsten Hilbert wrote: - My suggestion would be: - call gnumed.py with the python -m ... option if that works - this would rid us of that hardcoded path - a great thing - leave modules where they are and GNUmed finds them by default - if the Debian package maintainers want to put packages elsewhere, fine, as long as the rest of the code finds them by default - I am just adverse to including more detection logic for no good reason that I can see - If that had been followed no problem would have come up. Unfortunately thi is not true. Just try to apply the same packaging as it was used for 0.3.12 for 0.4.x. It just fails and I found no reason. If it would not have failed I would have uploaded a 0.4.0 package immediately. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Help] Failed to apply new Python policy to GNUmed packages
On Sun, 29 Mar 2009, Emilio Pozuelo Monfort wrote: You're missing a 'export' before setting the variable (or call python in the same line you set it). Uhm - stupid me. That's a beginners fault ... :-( In the first releases of gnumed-client package I used Gnumed.pth but dropped this since I used python-support (version 0.3.x). Does this mean I might use this again? You don't need it, you can remove it (I've seen you've added it back). It is actually not *installed* into the package but I kept it up to date in the packaging directory. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Help] Failed to apply new Python policy to GNUmed packages
On Sun, 29 Mar 2009, Emilio Pozuelo Monfort wrote: In that case the .pyc files won't be loaded, but the .py ones, I guess (please somebody correct me if I'm wrong). Nothing to worry about as people will usually be using the default interpreter. I admit I really prefered the former behaviour of python-support to precompile for all Python interpreter versions which are mentioned in pyversions. If you install a package at a certain point in time and after this installation the python interpreter version will change the *.pyc files won't be used. If the *.pyc files would be generated for all available Python versions in a separate place you might even be able to trigger generating *.pyc files for all python-support controlled packages later on once a new Python interpreter will be installed. You don't need it, you can remove it (I've seen you've added it back). That was one of my ill-fated suggestions - it would have worked but it is clearly better if things work without it. That would defeat the purpose of placing the modules in a private location, so yes, better to remove it :) As I said: The Gnumed.pth file is not installed into the package since package version 0.2-1 (see changelog). It just remains in the packaging dir - perhaps even this is not needed but does not really harm. Kind regards and thanks for your help Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Verifying module dependencies (Was: [Help] Failed to apply new Python policy to GNUmed packages)
On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote: I got an error that mx.DateTime can't be imported, so you probably need to depend on python-egenix-mxdatetime). Thanks to Emilio I was able to fix the gnumed-client package which was in fact lacking the python-egenix-mxdatetime build dependency. Thinking about this I wonder how we could make sure that this kind of problems will be easier to detect. Detecting missing Build-Depends is easy if you use pbuilder but detecting runtime depends IMHO needs to install a clean chroot or whatever. Wouldn't it be possible to parse all import statements in the code and verify that the package which provide the imports are listed in the Depends of a package? I have no idea whather this makes sense or how much effort this takes - just a thought. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
