Re: __file__ is a disease
Le samedi 30 janvier 2010 à 19:20 -0500, Barry Warsaw a écrit : > I think it's not so much that pkg_resources is complex, but that it has a lot > of extra API that most people won't need. Hopefully the distutils-sig will > distill the essential pieces of that and push it into the stdlib. I was > trying to see if you objected to the specific explicit use of __file__ or the > concept of co-locating data files with the source code, since that violates > the FHS, but isn't really changed by use of pkg_resources. Co-locating data with an API to access it brings Python on par with what Java can do. That’s not really a good reference, I’m afraid, but it still means progress. > The advantage of > using an API is that it can abstract away changes in policy or practice. Indeed but it would require to stop developing for a moment and try designing. I have stopped following the distutils developments when people proposed to introduce yet another layer of symlink farms to work around the current design issues of pkg_resources; I have stopped hoping to see something correct come of upstream since then. > >Basically, I’d say it tries to address the problem at the wrong level: > >build/installation issues should be addressed by the build system, not > >by the code. > > Except that this is where build/installation and code requirements intersect. > The code at run time needs certain data files. It doesn't really care where > they are, but it has to guarantee that it can find them. The installation > system may care deeply where such files go so it has to communicate this to > the code at run-time. Using an abstraction like pkg_resources helps bridge > that gap. It’s a hammer to crush a mosquito. The only thing you need is a few file paths, and there has been a cross-language way to do that for decades: string replacement. When a solution turns out to be more complex and less flexible than string replacement, there’s a big problem with it. > Maybe. IME though, many folks who are very comfortable contributing Python > code to a project run away in abject fear when asked to update autotools > files. IMO, they're a necessary evil for complex C or C++ projects, but way > too heavy for simple Python libraries or applications. If you have some time, please have a look at e.g. the hamster-applet upstream packaging, and tell me what’s complicated with it. I’m afraid the main problem Python developers find with it is that it’s not written in Python. So it’s more a NIH problem - the same Java has. > >There are huge projects that use the autotools without needing to jump > >through hoops. A simple look at NumPy and its 1+ lines of specific > >Python code just to be able to build the C pieces should be enough to > >convince anyone to use a better tool. > > Maybe so, but that seems like an extreme example for the Python universe of > stuff. Most libraries don't need anything nearly as complicated. Indeed, but there are some projects just as complicated out there, and apart from (an arguably high number of) upstreams who like to make their life more complicated, they don’t need 1 lines of build scripts. > >I’m not implying the autotools don’t have flaws: the insanity of libtool > >bugs, the arcanes of m4 and the gazillions of broken m4 scripts that lie > >around… But these flaws are about features that don’t even exist in > >Python-specific tools. > > For most Python libraries and applications, they're YAGNI anyway. If there > are specific problems with Python tools for the majority of straightforward > Python libraries, let's fix those tools. But I think they mostly work, and > where they don't, the distutils-sig is paving the way of the future. How is the following YAGNI? AC_CONFIG_FILES(foo.py) -- .''`. 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
Join Python Module team
Hi, I would like to join Debian Python Module team at Alioth, my alioth id is deepak-guest. -- Thanks Deepak Tripathi E3 71V3 8Y C063 (We Live By Code) http://deepaktripathi.blogspot.com
Re: Join Python Module team
[Deepak Tripathi, 2010-01-31] > I would like to join Debian Python Module team at Alioth, my alioth id is > deepak-guest. sure, but... why do you want to join us? http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ideal directory structure?
On 31/01/10 02:05, Pietro Battiston wrote: As far as I know, I'm not supposed to decide or even know how users will install my application... Unfortunately, all the files are supposed to go to sys.prefix (/usr on most Linux distros) [1]. I still don't understand why this has been patched to make it so difficult to understand. As a newbie, I look up distutils on the net, find the Python documentation, believe that files will be installed under sys.prefix and find that they are installed under sys.prefix + '/local'. Little do I know that somewhere in between somebody has done something that isn't mentioned in the one source I'd like to believe. It is clearly breaking official Python documentation. I've read a little about why this has been done (some archives of Matthias' mails), but all of it went over my head. Umang [1] http://docs.python.org/distutils/setupscript.html#installing-additional-files -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ideal directory structure?
[Umang, 2010-01-31] > Unfortunately, all the files are supposed to go to sys.prefix (/usr > on most Linux distros) [1]. I still don't understand why this has > been patched to make it so difficult to understand. As a newbie, I > look up distutils on the net, find the Python documentation, believe > that files will be installed under sys.prefix and find that they are > installed under sys.prefix + '/local'. Little do I know that > somewhere in between somebody has done something that isn't mentioned > in the one source I'd like to believe. It is clearly breaking > official Python documentation. users (guided by module/application authors) do things like: $ sudo easy_install foo or $ sudo python ./setup.py instal and thus breaking system packages. To make it a little bit less painful (and follow FHS) Debian's python (since 2.6) installs to /usr/local by default. This way system packages will still be broken (/usr/local is higher in sys.path) but at least it will be easier to fix it (Python packaging system doesn't have a *working* uninstall functionality). Additionally system's python uses dist-packages instead of site-packages so local installations of python itself will not interfere with the one from Debian package. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Re: Ideal directory structure?
Now that this discussion has split into various sub-discussions, I don't mind digressing... On 31/01/10 20:29, Piotr Ożarowski wrote: To make it a little bit less painful (and follow FHS) Debian's python (since 2.6) installs to /usr/local by default. This way system packages will still be broken (/usr/local is higher in sys.path) but at least it will be easier to fix it (Python packaging system doesn't have a *working* uninstall functionality). Additionally system's python uses dist-packages instead of site-packages so local installations of python itself will not interfere with the one from Debian package. But I'll never find my data files in sys.prefix + path_i_asked_distutils_to_install_to. So what according to you, is the right way to go about distributing? This situation is definitely not ideal. Thanks Umang -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ideal directory structure?
On Jan 31, 2010, at 08:53 PM, Umang wrote:
>But I'll never find my data files in sys.prefix +
>path_i_asked_distutils_to_install_to. So what according to you, is the
>right way to go about distributing? This situation is definitely not ideal.
The Pythonic way (IMO) is to use pkg_resources:
http://peak.telecommunity.com/DevCenter/PkgResources
and especially the resource_string() and resource_stream() APIs. This means
if your data file is under mypkg.mydata (yes, you'll have an __init__.py in
your data directory), you can access your data file by either:
mydata = pkg_resources.resource_string('mypkg.mydata', 'foo.dat')
or
mydata_fileobj = pkg_resources.resource_stream('mypkg.mydata', 'foo.dat')
The module contains a lot of extra stuff that I find is rarely if ever used,
but might make for an interesting read. :)
Hope that helps,
-Barry
signature.asc
Description: PGP signature
Re: Ideal directory structure?
On 31/01/10 21:13, Barry Warsaw wrote: The Pythonic way (IMO) is to use pkg_resources: Great. So distutils is not sufficient to get everything done. I'm not a fan of complications, so I'm going to postpone that long read. For now at least. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ideal directory structure?
[Barry Warsaw, 2010-01-31] > On Jan 31, 2010, at 08:53 PM, Umang wrote: > > >But I'll never find my data files in sys.prefix + > >path_i_asked_distutils_to_install_to. So what according to you, is the > >right way to go about distributing? This situation is definitely not ideal. > > The Pythonic way (IMO) is to use pkg_resources: ... and when one will want to follow FHS and use --install-data (provided by Python, sic!) acordingly, it will fail, at least in Python << 2.7 also: pkg_resources is not in standard library, so I'd use one of these: * use something that keeps track of --install-data equivalent (f.e. automake or even pure Makefiles, if possible) * adjust setup.py to do what distutils/setuptools/distribute doesn't (save locations in .py files at install time) * postpone the release date until Python developers will include something based on pkg_resources in stdlib (that works fine with --install-data) ;-) anyway, even if you'll decide to hardcode the path somewhere, please at least make it in *one* place (so that it will be easier to patch). -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Re: Join Python Module team
Hi, i do work with debian-perl and debian-ruby team, now i have started packaging python module. I have couple of python related ITP and would like to maintain with the team :) . Thanks Deepak On Sun, Jan 31, 2010 at 7:16 PM, Piotr Ożarowski wrote: > [Deepak Tripathi, 2010-01-31] > > I would like to join Debian Python Module team at Alioth, my alioth id is > > deepak-guest. > > sure, but... why do you want to join us? > http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin > -- > Piotr Ożarowski Debian GNU/Linux Developer > www.ozarowski.pl www.griffith.cc www.debian.org > GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 > > > -- > To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > > -- Deepak Tripathi E3 71V3 8Y C063 (We Live By Code) http://deepaktripathi.blogspot.com
Re: RFS: foolscap (updated package)
[Elliot Murphy, 2010-01-31] > All done, committed to svn uploaded -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
python-wxgtk2.6 setup error
Aptitude is giving me this error: Setting up python-wxgtk2.6 (2.6.3.2.2-4+b1) ... file does not exist: /usr/lib/python2.6/dist-packages/wxversion.py pycentral: pycentral pkginstall: error byte-compiling files (260) pycentral pkginstall: error byte-compiling files (260) dpkg: error processing python-wxgtk2.6 (--configure): subprocess installed post-installation script returned error exit status 1 Is this a known bug or do I have something wrong? -- "The ideas I stand for are not mine. I borrowed them from Socrates. I swiped them from Chesterfield. I stole them from Jesus. And I put them in a book. If you don't like their rules, whose would you use?" -- Dale Carnegie Rick Pasottor...@niof.nethttp://www.niof.net -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: python-wxgtk2.6 setup error
* Rick Pasotto , 2010-01-31, 11:28: Setting up python-wxgtk2.6 (2.6.3.2.2-4+b1) ... file does not exist: /usr/lib/python2.6/dist-packages/wxversion.py pycentral: pycentral pkginstall: error byte-compiling files (260) pycentral pkginstall: error byte-compiling files (260) dpkg: error processing python-wxgtk2.6 (--configure): subprocess installed post-installation script returned error exit status 1 http://bugs.debian.org/566960 -- Jakub Wilk signature.asc Description: Digital signature
