PEP 345 - request for comments
Dear Maintainers, PEP 345 [1] describes version 1.2 of the PKG-INFO file that will be shipped with Python distributions in the future. Among other fields it also includes a 'Requires-External' field, which is, as of now, defined like this: --- snip --- Each entry contains a string describing some dependency in the system that the package is to be used. This field is intended to serve as a hint to downstream package maintainers, and has no semantics which are meaningful to the distutils package. The format of a requirement string is a name of an external dependency, optionally followed by a version declaration within parentheses. A version declaration is a series of conditional operators and version numbers, separated by commas. Conditional operators must be one of "<", ">", "<=", ">=", "==", and "!=". If no operator is provided with a version, the "==" operator is used by default. Because they refer to non-Python software releases, version numbers for this field are not required to conform to the format specified in PEP 386 [3]: they should correspond to the version scheme used by the external dependency. Any number of conditional operators can be specified, e.g. the string ">1.0, !=1.3.4, <2.0" is a legal version declaration. Notice that there's is no particular rule on the strings to be used. Examples: Requires-External: C Requires-External: libpng (>=1.5) --- snip --- Would Debian maintainers use this field to extract dependencies of a Python package that have to be handled by the system's package manager? Does the proposed format match your requirements? Are there any changes your would like to see incorporated, so that this field eases your packaging work? There are no plans to normalise entries in this field to a canonical name by PyPii [2], which basically means that the mapping between the identifiers used by upstream and Debian's package names has to be handled by Debian and/or done by the upstream authors. It would be great if you could provide some comments, suggestions or criticism on this topic. kind regards [1] http://www.python.org/dev/peps/pep-0345/ [2] http://mail.python.org/pipermail/distutils-sig/2009-November/014617.html -- .''`. Wolodja Wentland : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: PEP 345 - request for comments
Le mercredi 18 novembre 2009 à 10:02 +0100, Wolodja Wentland a écrit : > PEP 345 [1] describes version 1.2 of the PKG-INFO file that will be > shipped with Python distributions in the future. > Requires-External: C > Requires-External: libpng (>=1.5) > Would Debian maintainers use this field to extract dependencies of a > Python package that have to be handled by the system's package manager? No, it is clearly not possible to automate such a thing. You should use pkg-config, possibly extending it with Python fields, instead of reinventing the wheel. > Does the proposed format match your requirements? Are there any changes > your would like to see incorporated, so that this field eases your > packaging work? If upstream maintainers update this field correctly, it would ease packaging work, but not automate it. With the proposal as is, it is strictly similar to making mandatory the documentation of dependencies. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: PEP 345 - request for comments
On Wed, Nov 18, 2009 at 16:03 +0100, Josselin Mouette wrote: > Le mercredi 18 novembre 2009 à 10:02 +0100, Wolodja Wentland a écrit : > > PEP 345 [1] describes version 1.2 of the PKG-INFO file that will be > > shipped with Python distributions in the future. > > > Requires-External: C > > Requires-External: libpng (>=1.5) > > > Would Debian maintainers use this field to extract dependencies of a > > Python package that have to be handled by the system's package manager? > No, it is clearly not possible to automate such a thing. > You should use pkg-config, possibly extending it with Python fields, > instead of reinventing the wheel. I agree. Automation based on this information is clearly only possible if the requirements were listed specifically for each Linux distribution and would use the actual package names used by, for example, Debian. Even then this field might only serve as a hint to, say dh_make, in the initial debianisation of the original source archive. > > Does the proposed format match your requirements? Are there any changes > > your would like to see incorporated, so that this field eases your > > packaging work? > If upstream maintainers update this field correctly, it would ease > packaging work, but not automate it. With the proposal as is, it is > strictly similar to making mandatory the documentation of dependencies. The documentation is not mandatory and I guess that a lot of upstream authors will not even bother to list these external dependencies. I just wanted to ask if you actually see any benefit in including this field in the PEP. There are a couple of other proposals and PEPs that you might be interested in. You can find a - incomplete - overview at: [1] http://wiki.python.org/moin/Distutils/DiscussionOverview It would be great if you could have a look at the PEPs and proposals and point out anything that you would like to see changed or included. thanks a lot! P.S. I am subscribed to this list, so there is no need to CC me. -- .''`. Wolodja Wentland : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: PEP 345 - request for comments
On Wed, Nov 18, 2009 at 04:03:32PM +0100, Josselin Mouette wrote: > Le mercredi 18 novembre 2009 à 10:02 +0100, Wolodja Wentland a écrit : > > PEP 345 [1] describes version 1.2 of the PKG-INFO file that will be > > shipped with Python distributions in the future. > > > Requires-External: C > > Requires-External: libpng (>=1.5) > > > Would Debian maintainers use this field to extract dependencies of a > > Python package that have to be handled by the system's package manager? > > No, it is clearly not possible to automate such a thing. > > You should use pkg-config, possibly extending it with Python fields, > instead of reinventing the wheel. > > > Does the proposed format match your requirements? Are there any changes > > your would like to see incorporated, so that this field eases your > > packaging work? > > If upstream maintainers update this field correctly, it would ease > packaging work, but not automate it. With the proposal as is, it is > strictly similar to making mandatory the documentation of dependencies. That is indeed how distutils-sig consensus currently sees that field, at least in my understanding. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS: python-slimmer
Dear mentors, I am looking for a sponsor for my package "python-slimmer". * Package name: python-slimmer Version : 0.1.30-1 Upstream Author : Peter Bengtsson * URL : http://pypi.python.org/pypi/slimmer/ * License : Python Software Foundation License Section : python It builds these binary packages: python-slimmer - HTML, XHTML, CSS, JavaScript optimizer The package appears to be lintian clean. The upload would fix these bugs: 556604 My motivation for maintaining this package is: python replace for YUM CSS, JavaScript optimizer. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/python-slimmer - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/python-slimmer/python-slimmer_0.1.30-1.dsc I would be glad if someone uploaded this package for me. Kind regards Janos Guljas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Solved] importing modules at IDLE startup
Le lundi 16 novembre 2009 à 16:09 -0800, Mark Voorhies a écrit : > A good way to test the environment that python/idle is seeing is: > import os > os.environ["PYTHONSTARTUP"] Here are the results: >>> import os >>> os.environ["PYTHONSTARTUP"] '/home/fred/.pythonrc.py' So for me the variable is correctly initialized at login. > When you start a bash terminal session (e.g., via gnome-terminal) ~/.bashrc > is > sourced and the resulting environment is passed to any programs started from > that terminal session. I believe that the environment seen by programs > launched from the gnome menu is set up through some combination of your login > manager (e.g., gdm) and Xsession, in a fairly distro dependent way. In my > hands, this means that I can see my ~/.bashrc environment from python or idle > launched from a bash shell, but not from the gnome menu. OK, so in my case it seems that my .bashrc is executed at login and known by gnome. > If you don't want to muck around with Xsession config files, and you're > hacking the idle-python2.5 script anyway, you can modify the environment from > within the script: > > > #! /usr/bin/python2.5 -Qnew > import os > os.environ["PYTHONSTARTUP"] = "/home/fred/.pythonrc.py" > from idlelib.PyShell import main > if __name__ == '__main__': > main() > - OK So, now my problem is entirely solved under linux. I went into XP to see if I could analogously solve it. Here are the things I did: 1) I created a C:\Python26\pythonrc.py file containing the two lines from __future__ import division from math import * 2) I created an environment variable PYTHONSTARTUP pointing to pythonrc.py 3) I changed the program associated to .py files so that they are now associated with the command C:\Python26\pythonw.exe -Qnew C:\Python26\Lib\idlelib\idle.pyw -n -e -s 4) I created a C:\Python26\pythonw.bat file containing the line start C:\Python26\pythonw.exe -Qnew C:\Python26\Lib\idlelib\idle.pyw -n -e -s 5) I added a new link in menu Start-->Programs-->Python26 which points to the .bat file (I renamed the name of the link and changed its icon) Note that step 4) and 5) where only to give the user a possibility to start IDLE "alone", without double-clicking (or right-clicking) on a file. I'm not sure if there is a simpler way than steps 4)-5). So globally my problem is solved. By the way, I also asked myself whether I could also indicate, at IDLE startup, whitch coding system is to be used, so that students never have to add the line # -*- coding: cp1252 -*- at the top of their script file (on the PCs we have in my high school). Do you know if I can do this (maybe with the os module)? Thank's a lot for your precious help! Gratefully, Frédéric. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
