Re: [Distutils] setup_requires for dev environments

On 03/16/2015 02:53 PM, Daniel Holth wrote: No one should be asked to learn how to extend distutils, and in practice no one knows how. People have been begging for years for working setup_requires, far longer than I've been interested in it, and all they want to do is import fetch_version setup

Re: [Distutils] Proposal: Restrict the characters in a project name

On Thu, 2013-05-16 at 07:53 +1000, Nick Coghlan wrote: > One of my major goals for metadata 2.0 is better packaging > interoperability with the Fedora and Debian ecosystems. Since those > formally restrict the set of permitted characters, and the existing > Python packaging ecosystem informally res

Re: [Distutils] Buildout 2.0.0 released

On Sun, 2013-02-10 at 13:24 -0500, Jim Fulton wrote: > I'm very happy, finally, to have released buildout 2.0.0. > > Much has changed from buildout 1: > > http://pypi.python.org/pypi/zc.buildout/2.0.0#id3 > > Installation instructions: > > http://pypi.python.org/pypi/zc.buildout/2.0.0#insta

Re: [Distutils] Some clarifications and/or corrections to PEP 376

On Fri, 2013-01-04 at 11:43 +, Paul Moore wrote: > On 4 January 2013 11:06, Antonio Cavallo wrote: > > And I'm talking about **applications** (eg. some code + some library > > depending on an installed python stack) vs **libraries** (code simply > > installed along the current python stack). >

Re: [Distutils] Some clarifications and/or corrections to PEP 376

On Fri, 2013-01-04 at 09:17 +, Vinay Sajip wrote: > > > > > From: PJ Eby > > > FWIW, the original reason I argued for relative paths in PEP 376 is > > supporting installations that are shared across architectures for > > cross-platform development. At OSAF, it was common to have a single

Re: [Distutils] zc.buildout 2.0.0a4 released

On 11/19/2012 09:47 PM, Alex Clark wrote: On 2012-11-20 02:00:34 +, Tres Seaver said: Amen. Let's not coddle folks who blindly install without checking, to the detriment of those who pay attention and will help find and fix bugs. Those who need the coddling should be paying somebody for th

Re: [Distutils] zc.buildout 2.0.0a4 released

On 11/19/2012 06:19 PM, Jim Fulton wrote: On Mon, Nov 19, 2012 at 6:00 PM, Alex Clark wrote: Ugh, sorry. I wonder if we can get Richard Jones or Martin von Löwis to modify PyPI such that "hiding" really means hiding (CC'ing catalog-sig). That would be very bad. Old releases are often hidden.

Re: [Distutils] distlib and data files => resources ?

On 11/18/2012 05:55 PM, Tarek Ziadé wrote: On 11/18/12 11:45 PM, Chris McDonough wrote: I don't really take exception to having such a feature (although I would be unlikely to use it), but I do take exception to the first paragraph of the description you pointed at: "This section

Re: [Distutils] distlib and data files => resources ?

On 11/18/2012 05:33 PM, Tarek Ziadé wrote: On 11/18/12 11:15 PM, Chris McDonough wrote: On 11/18/2012 05:08 PM, Vinay Sajip wrote: Tarek Ziadé ziade.org> writes: Having a indirection like distutils2's resources allows the data files to live alongside the code in development a

Re: [Distutils] distlib and data files => resources ?

On 11/18/2012 05:08 PM, Vinay Sajip wrote: Tarek Ziadé ziade.org> writes: Having a indirection like distutils2's resources allows the data files to live alongside the code in development and to be installed wherever that's desired by the distro, without breaking the code as long as it uses the

Re: [Distutils] Differences in PEP386 and setuptools

On Thu, 2012-09-27 at 16:15 -0700, Toshio Kuratomi wrote: > On Thu, Sep 27, 2012 at 05:00:56PM -0500, Brad Allen wrote: > > On Thu, Sep 27, 2012 at 2:45 PM, Toshio Kuratomi wrote: > > > > > However, now that you mention it, ISTR that this is the way that it was > > > originally and the lack of pr

Re: [Distutils] zip imports ftw

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 wa

Re: [Distutils] zip imports ftw

On Sun, 2012-09-16 at 08:07 -0400, Daniel Holth wrote: > Of course the major potentially non obvious caveats are that a lot of python > code doesn't use the API to load data from the importer path, instead using > __file__ and assuming everything is one, and that sometimes (shared > libraries) t

Re: [Distutils] optional binary compilation under future installation tools

On Thu, 2012-09-13 at 10:44 +0200, Tarek Ziadé wrote: > On 9/13/12 10:15 AM, Chris McDonough wrote: > > Some packages we maintain currently provide largely identical > > side-by-side implementations of features: one implementation is written > > in C, the other implementation

Re: [Distutils] extension to pep 376: "develop" installation

On Thu, 2012-09-13 at 03:26 -0400, Chris McDonough wrote: > That's the basics. One additional thing implementations in installer tools of "develop" should probably do: cause test-time-only dependencies to be installed. - C ___ Dist

[Distutils] optional binary compilation under future installation tools

Some packages we maintain currently provide largely identical side-by-side implementations of features: one implementation is written in C, the other implementation is written in Python. The C module is just an optimized version of the Python code. There is logic at module scope within modules in

Re: [Distutils] Extension: Entry-Point

On Thu, 2012-09-13 at 01:50 -0400, Daniel Holth wrote: > I propose mapping a typical entry_points.txt to Metadata 1.3 like so: > > [pyramid.scaffold] > starter=pyramid.scaffolds:StarterProjectTemplate > zodb=pyramid.scaffolds:ZODBProjectTemplate > alchemy=pyramid.sc

[Distutils] extension to pep 376: "develop" installation

I propose an extension to PEP 376 to support the development of projects such that: - Installation tools should expect to need to cope with files present in purelib named "foo.dist-link". Each of these files will be of the form "/path/containing/foo.dist-info\nreldir" For example, the conte

Re: [Distutils] command hooks...

On 05/21/2012 04:59 PM, Tarek Ziadé wrote: On 5/16/12 6:26 PM, Chris McDonough wrote: On 05/16/2012 02:55 AM, Tarek Ziadé wrote: On 5/16/12 3:58 AM, Chris McDonough wrote: Adding two more (packaging and distutils2) which are similarly semi-documented and which don't even solve the pro

Re: [Distutils] command hooks...

On 05/16/2012 02:55 AM, Tarek Ziadé wrote: On 5/16/12 3:58 AM, Chris McDonough wrote: Adding two more (packaging and distutils2) which are similarly semi-documented and which don't even solve the problems that the previous ones do would serve no purpose, and baking them into Python itself

Re: [Distutils] command hooks...

On 05/16/2012 02:35 AM, Tarek Ziadé wrote: I know the idea of having packaging in the stdlib is something some people disliked, from day 1. And if I recall correctly, you did not like this either back then. I've always been pro-stdlib-contains-a-package-installer-and-machinery, and I still am.

Re: [Distutils] command hooks...

On 05/15/2012 04:39 PM, Éric Araujo wrote: Hi again, Le 01/05/2012 14:28, Paul Moore a écrit : On 1 May 2012 17:40, Chris McDonough wrote: Is there a PEP for the "packaging" package? Is there any sort of unfinished business I can help with? AFAIK, there's no specific PEP for p

[Distutils] packaging in python 3.3 (was Re: command hooks...)

On 05/01/2012 12:40 PM, Chris McDonough wrote: Georg Brandl was trying to herd cats on outstanding PEPs today: http://mail.python.org/pipermail/python-dev/2012-May/119157.html Is there a PEP for the "packaging" package? Is there any sort of unfinished business I can help with?

Re: [Distutils] command hooks...

On 05/01/2012 02:28 PM, Paul Moore wrote: On 1 May 2012 17:40, Chris McDonough wrote: Georg Brandl was trying to herd cats on outstanding PEPs today: http://mail.python.org/pipermail/python-dev/2012-May/119157.html Is there a PEP for the "packaging" package? Is there any sort of

Re: [Distutils] command hooks...

On 04/21/2012 01:51 AM, Éric Araujo wrote: Hi again, Is Distutils2 kind of your baby? Simply, you are the only one working on it! It’s more like my foster kid. At first there was distutils, in the standard library since 1999. After a few years it stopped being actively developed, and people

[Distutils] packaging docs

What state are the docs for "packaging" in right now? Of: http://docs.python.org/dev/packaging/setupcfg.html and http://docs.python.org/dev/packaging/introduction.html ... the latter comes directly after the former in navigation order. The former describes setup.cfg-driven and presumably pyse

Re: [Distutils] new zc.buildout and virtualenv no longer friends?

On Fri, 2010-04-30 at 08:57 +0200, Rok Garbas wrote: > i ment on bootstrap .. > > python bootstrap.py -v1.4.3 Thanks Rok. With that hint, I was able to work around it in a virtualenv by: - Using the bootstrap.py from the 1.4.3 tag (

Re: [Distutils] new zc.buildout and virtualenv no longer friends?

On Fri, 2010-04-30 at 08:57 +0200, Rok Garbas wrote: > i ment on bootstrap .. > > python bootstrap.py -v1.4.3 With the bootstrap.py I had been using (pre --version option apparently): [chr...@thinko deformsite]$ bin/python bootstrap.py -v1.4.3 Error: Invalid option -1 With the bootstrap.py fr

[Distutils] new zc.buildout and virtualenv no longer friends?

I have a relatively simple buildout that is a directory which is also a virtualenv (the buildout directory was prepped after checkout with Python 2.4 "virtualenv --no-site-packages ." and the bootstrap was run using the resulting "bin/python"). Just now, I had to rerun bin/buildout in that existin

[Distutils] new zc.buildout and virtualenv no longer friends?

I have a relatively simple buildout that is a directory which is also a virtualenv (the buildout directory was prepped after checkout with Python 2.4 "virtualenv --no-site-packages ." and the bootstrap was run using the resulting "bin/python"). Just now, I had to rerun bin/buildout in that existin

Re: [Distutils] Colour this bikeshed: Name for setuptools fork

On 7/17/09 11:47 PM, Ben Finney wrote: Chris McDonough writes: You gotta realize that fielding all these bikeshed emails takes a lot of time; if it gets named "distribute" or one of the two options from the poll, so be it. Give the poor man a mail-responding rest. ;-) Agreed. T

Re: [Distutils] Colour this bikeshed: Name for setuptools fork

I'd be quite happy if Tarek ignored the meta-drivel in this thread and made some checkins, even if the project was named the empty string. You gotta realize that fielding all these bikeshed emails takes a lot of time; if it gets named "distribute" or one of the two options from the poll, so be

Re: [Distutils] [Python-Dev] PEP 376 - from PyPM's point of view

I've been trying to follow this discussion now for weeks. The signal to noise ratio is pretty low. I'd love to have an stdlib solution for distribution packaging and installation. But I think we might as well pack it up and go home if the folks whom are contributing to the discussion "recreat

Re: [Distutils] [Python-Dev] how to easily consume just the parts of eggs that are good for you

zooko wrote: > > On Mar 26, 2008, at 7:34 PM, Chris McDonough wrote: >> zooko wrote: > > http://mail.python.org/pipermail/python-dev/2008-March/078243.html > >>> Here is a simple proposal: make the standard Python "import" >>> mechanism notice

Re: [Distutils] [Python-Dev] how to easily consume just the parts of eggs that are good for you

zooko wrote: > Folks: > > Here is a simple proposal: make the standard Python "import" > mechanism notice eggs on the PYTHONPATH and insert them (into the > *same* location) on the sys.path. > > This eliminates the #1 problem with eggs -- that they don't easily > work when installing them

[Distutils] run zc.recipe.egg tests...

When I run the zc.recipe.egg-1.0.0 tests via "setup.py test" (after unpacking from the distribution tarball), I get the below-mentioned failures. Is there another way I should be running the tests so they pass, or are these failures genuine? - VC """ [EMAIL PROTECTED] zc.recipe.egg-1.0.0]$ py

Re: [Distutils] alternatives to zc.buildout?

Martin Aspeli wrote: > Chris McDonough wrote: >> Martin Aspeli wrote: >>> Tres Seaver wrote: >>>> -BEGIN PGP SIGNED MESSAGE- >>>> Hash: SHA1 >>>> >>>> Chris Withers wrote: >>>>> Hi All, >>>>>

Re: [Distutils] alternatives to zc.buildout?

Martin Aspeli wrote: > Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Chris Withers wrote: >>> Hi All, >>> > > >> The standard installs for repoze.zope2, repoze.grok, repoze.plone, etc. >> all assume a virtualenv, and add scripts which turn the vanilla >> virtualenv i

Re: [Distutils] setuptools fails to install package data from ZIP distribution

In my experience, that's usually a problem that happens when you do "python setup.py sdist" using: - a setup.py expects that "find_package_data()" will find package data based on searching for things checked into version control. - a source tree that isn't checked out from version control

[Distutils] licenses for ez_setup and virtual_python

We'd like to distribute ez_setup.py and virtual_python.py with a good number of our packages. I suspect ez_setup.py is licensed under the same dual ZPL/PSF license as is setuptools. I'm not sure how virtual_python.py is licensed (I got it from From http:// peak.telecommunity.com/dist/virtu

Re: [Distutils] virtual-python.py, sys.prefix, and Mac

FWIW, the same thing seems to happen for me on Tiger using the original virtual-python.py against the Apple-compiled Python that ships with it: [EMAIL PROTECTED] macsandbox]$ /usr/bin/python ~/bin/virtual-python.py --prefix=.Creating ./lib/python2.3 Creating ./lib/python2.3/site-packages Cre

Re: [Distutils] profiling setuptools console scripts

On Sep 5, 2007, at 1:52 PM, Phillip J. Eby wrote: > At 01:03 PM 9/5/2007 -0400, Chris McDonough wrote: >> This is very minor, but I recently ran across a case where I wanted >> to profile some code invoked that is invoked by a setuptools >> console_script. The generated

[Distutils] profiling setuptools console scripts

This is very minor, but I recently ran across a case where I wanted to profile some code invoked that is invoked by a setuptools console_script. The generated script is in the form: sys.exit( load_entry_point('supervisor==3.0a2', 'console_scripts', 'supervisord')() ) Due to the explici