[Distutils] Confused about distutils2/packaging
Hi, I'm eagerly looking forward to the improvements that distutils2/packaging will (hopefully) bring, and I very much appreciate the efforts of those involved. However, I'm a bit confused about the status. On http://pypi.python.org/pypi/Distutils2 it says packaging is included in Python 3.3, and on http://docs.python.org/dev/packaging/ there is guidance for how to write a .cfg file. On the other hand, on http://python.org/dev/peps/pep-0398/ (the 3.3 release schedule) it says that the inclusion of packaging is deferred. Which is it? Maybe it's a good idea to make the different docs consistent. Thanks, Almar -- Almar Klein, PhD Science Applied phone: +31 6 19268652 e-mail: a.kl...@science-applied.nl ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Confused about distutils2/packaging
It part of 3.3 for awhile, but it was ultimately removed because it was determined that it was not ready for inclusion in the stdlib. On Monday, September 17, 2012 at 3:44 AM, Almar Klein wrote: Hi, I'm eagerly looking forward to the improvements that distutils2/packaging will (hopefully) bring, and I very much appreciate the efforts of those involved. However, I'm a bit confused about the status. On http://pypi.python.org/pypi/Distutils2 it says packaging is included in Python 3.3, and on http://docs.python.org/dev/packaging/ there is guidance for how to write a .cfg file. On the other hand, on http://python.org/dev/peps/pep-0398/ (the 3.3 release schedule) it says that the inclusion of packaging is deferred. Which is it? Maybe it's a good idea to make the different docs consistent. Thanks, Almar -- Almar Klein, PhD Science Applied phone: +31 6 19268652 (tel:%2B31%206%2019268652) e-mail: a.kl...@science-applied.nl (mailto:a.kl...@science-applied.nl) ___ Distutils-SIG maillist - Distutils-SIG@python.org (mailto:Distutils-SIG@python.org) http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zip imports ftw
On Sep 16, 2012, at 03:33 PM, Daniel Holth wrote: It is because the file has a controversial coding style, with up to 25 lines of whitespace between classes, and includes functionality for eggs and some other stuff that was unwanted on top of the resources stuff that partly made its way into pkgutil. Right, which is why I passively-aggressively suggested an API like it. :) I am really impressed with the file after seeing how easy it was to add PEP-345 and PEP-376 support to pkg_resources.py without having to present a different API to the user, and seeing how it provides a lot of what an installer needs especially being able to iterate over all the distributions in a particular folder, but I am glad it is not in the stdlib because I wouldn't have been able to do that if it was. Interesting, but of course, this is the same with any module in the stdlib. That's why it's (somewhat humorously) said the stdlib is where good modules go to die. ;) -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zip imports ftw
On Sep 16, 2012, at 03:40 PM, Chris McDonough wrote: On Sun, 2012-09-16 at 15:33 -0400, Daniel Holth wrote: It is because the file has a controversial coding style, with up to 25 lines of whitespace between classes, and includes functionality for eggs and some other stuff that was unwanted on top of the resources stuff that partly made its way into pkgutil. I think maybe there's also a latent notion floating around that a resource (aka non-Python files) shouldn't be addressable within Python packages aka. Python should only make it easy to address Python files in Python packages, but no other kind of file. I'm not sure I've ever seen any of the core dev team express this opinion, but I've seen it floating around elsewhere. Yeah. Personally, I think that's just silly. It's way, way, way too convenient to put some data files in your packages, and with pkg_resources, there's actually a principled way to do that consistently regardless of whether you're running from source or installed. I'm not even sure *not* putting your data files in your packages has any kind of common systematic support in Python. OTOH, it's definitely true that data files that people have to edit (e.g. configuration files) shouldn't live in your packages. That's just an invitation to violate all kinds of standards (he says, painfully aware of Mailman 2's mm_cfg.py file ;). -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zip imports ftw
On Mon, Sep 17, 2012 at 10:38 AM, Barry Warsaw ba...@python.org wrote: On Sep 16, 2012, at 03:40 PM, Chris McDonough wrote: On Sun, 2012-09-16 at 15:33 -0400, Daniel Holth wrote: It is because the file has a controversial coding style, with up to 25 lines of whitespace between classes, and includes functionality for eggs and some other stuff that was unwanted on top of the resources stuff that partly made its way into pkgutil. I think maybe there's also a latent notion floating around that a resource (aka non-Python files) shouldn't be addressable within Python packages aka. Python should only make it easy to address Python files in Python packages, but no other kind of file. I'm not sure I've ever seen any of the core dev team express this opinion, but I've seen it floating around elsewhere. Yeah. Personally, I think that's just silly. It's way, way, way too convenient to put some data files in your packages, and with pkg_resources, there's actually a principled way to do that consistently regardless of whether you're running from source or installed. I'm not even sure *not* putting your data files in your packages has any kind of common systematic support in Python. OTOH, it's definitely true that data files that people have to edit (e.g. configuration files) shouldn't live in your packages. That's just an invitation to violate all kinds of standards (he says, painfully aware of Mailman 2's mm_cfg.py file ;). -Barry I don't think pkg_resources's much better version of pkgutil.get_data is seriously under dispute. What's really missing in action is a better api than zipimport._zip_directory_cache to list everything on the importer path, not just the modules. distutils2 does try to add some support for 'data files not on sys.path' Bento will write, on request only, a Python file with the root paths used during installation. You get to choose the name. Something like: yourpackage/__config.py: SCRIPTS='/path/to/scripts' I think this is a better idea than .dist-info/RESOURCES being a file with original-path - installed-path for every file in the distribution. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] zip imports ftw
On Sun, Sep 16, 2012 at 3:33 PM, Daniel Holth dho...@gmail.com wrote: It is because the file has a controversial coding style, with up to 25 lines of whitespace between classes, and includes functionality for eggs and some other stuff that was unwanted on top of the resources stuff that partly made its way into pkgutil. I don't see why that couldn't be fixed though. As it is, almost every time I make a patch to distribute I clean things up a bit, in part because I have vim configured by default to run autopep8 and some other scripts on every Python file I open so I don't have to look at *quite* as much ugly code (this has proven very useful at work). I am really impressed with the file after seeing how easy it was to add PEP-345 and PEP-376 support to pkg_resources.py without having to present a different API to the user, and seeing how it provides a lot of what an installer needs especially being able to iterate over all the distributions in a particular folder, but I am glad it is not in the stdlib because I wouldn't have been able to do that if it was. Yes--I frequently have found myself wishing pkg_resources' availability could be assumed. Especially for getting handles to non-code resources, and for things like get_distribution(). Erik ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
