From ziade.tarek at gmail.com  Mon Mar  1 00:03:48 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 1 Mar 2010 00:03:48 +0100
Subject: [Distutils] layout and setup.py for packaging documentation
In-Reply-To: <6f4025011002281439t2dda1538gb488e20e0df6cc6c@mail.gmail.com>
References: <b61c19e71002281303s79c55e61u1eef6c82e07796ed@mail.gmail.com>
	<20100228221502.8CCAD3A40A7@sparrow.telecommunity.com>
	<6f4025011002281439t2dda1538gb488e20e0df6cc6c@mail.gmail.com>
Message-ID: <94bdd2611002281503s1e747cecp8dca9396dfe62bac@mail.gmail.com>

On Sun, Feb 28, 2010 at 11:39 PM, Michael Foord <fuzzyman at gmail.com> wrote:
>
>
> On 28 February 2010 22:14, P.J. Eby <pje at telecommunity.com> wrote:
>>
>> At 10:03 PM 2/28/2010 +0100, Jean Daniel wrote:
>>>
>>> Can this be simpler?
>>
>> Yes. ?Don't install docs with your package. ?People who want them
>> installed locally can just download your source install or use easy_install
>> -e.
>>
>> Also, if your module is popular enough that people make Linux system
>> packages for it, they will make sure the docs get put in a blessed install
>> location. ?Python doesn't currently have a blessed install location for
>> documentation, though perhaps it *should* have one in distutils2.
>
> How to include documentation in a package is a common question, so it would
> be great if distutils2 could deal with this issue.

As a matter of fact, we've worked on this during the sprints, and are
preparing a proposal
that will let people define a place for doc (and other stuff) and let
the OS packager decide where
it lands (with defaults per OS).

I'll post if there when its ready, hopefully soon

Tarek

From fuzzyman at gmail.com  Mon Mar  1 00:41:26 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Sun, 28 Feb 2010 23:41:26 +0000
Subject: [Distutils] layout and setup.py for packaging documentation
In-Reply-To: <94bdd2611002281503s1e747cecp8dca9396dfe62bac@mail.gmail.com>
References: <b61c19e71002281303s79c55e61u1eef6c82e07796ed@mail.gmail.com>
	<20100228221502.8CCAD3A40A7@sparrow.telecommunity.com>
	<6f4025011002281439t2dda1538gb488e20e0df6cc6c@mail.gmail.com>
	<94bdd2611002281503s1e747cecp8dca9396dfe62bac@mail.gmail.com>
Message-ID: <6f4025011002281541i75548b19n8f5c25f7472f33bb@mail.gmail.com>

On 28 February 2010 23:03, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> On Sun, Feb 28, 2010 at 11:39 PM, Michael Foord <fuzzyman at gmail.com>
> wrote:
> >
> >
> > On 28 February 2010 22:14, P.J. Eby <pje at telecommunity.com> wrote:
> >>
> >> At 10:03 PM 2/28/2010 +0100, Jean Daniel wrote:
> >>>
> >>> Can this be simpler?
> >>
> >> Yes.  Don't install docs with your package.  People who want them
> >> installed locally can just download your source install or use
> easy_install
> >> -e.
> >>
> >> Also, if your module is popular enough that people make Linux system
> >> packages for it, they will make sure the docs get put in a blessed
> install
> >> location.  Python doesn't currently have a blessed install location for
> >> documentation, though perhaps it *should* have one in distutils2.
> >
> > How to include documentation in a package is a common question, so it
> would
> > be great if distutils2 could deal with this issue.
>
> As a matter of fact, we've worked on this during the sprints, and are
> preparing a proposal
> that will let people define a place for doc (and other stuff) and let
> the OS packager decide where
> it lands (with defaults per OS).
>
> I'll post if there when its ready, hopefully soon
>

That sounds great.

Michael



>
> Tarek
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100228/4d3af46f/attachment.html>

From pje at telecommunity.com  Mon Mar  1 04:49:25 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 28 Feb 2010 22:49:25 -0500
Subject: [Distutils] layout and setup.py for packaging documentation
In-Reply-To: <6f4025011002281439t2dda1538gb488e20e0df6cc6c@mail.gmail.co
 m>
References: <b61c19e71002281303s79c55e61u1eef6c82e07796ed@mail.gmail.com>
	<20100228221502.8CCAD3A40A7@sparrow.telecommunity.com>
	<6f4025011002281439t2dda1538gb488e20e0df6cc6c@mail.gmail.com>
Message-ID: <20100301034925.D37403A40A0@sparrow.telecommunity.com>

At 10:39 PM 2/28/2010 +0000, Michael Foord wrote:
>On 28 February 2010 22:14, P.J. Eby 
><<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:
>At 10:03 PM 2/28/2010 +0100, Jean Daniel wrote:
>Can this be simpler?
>
>Yes.  Don't install docs with your package.  People who want them 
>installed locally can just download your source install or use easy_install -e.
>
>Also, if your module is popular enough that people make Linux system 
>packages for it, they will make sure the docs get put in a blessed 
>install location.  Python doesn't currently have a blessed install 
>location for documentation, though perhaps it *should* have one in distutils2.
>
>How to include documentation in a package is a common question, so 
>it would be great if distutils2 could deal with this issue.
>
>My current solution is, as Phillip suggests, to not include the docs 
>in distributions available via PyPI and to provide a more 'complete' 
>download separately.

That's not what I suggested, actually.  I said, don't *install* docs 
with your package.  Do *include* them in your source distribution, 
though, so people can download and read them with easy_install -e, 
and also so that those system packagers only have to download one 
tarball.  You also need only produce a standard source distribution 
(setup.py sdist upload) for PyPI.

In other words, Jean Daniel should retain his source layout of:

    wordish-1.0.2/
         setup.py
         wordish.py
         docs/
             index.html
             command-ref.html

And simply make sure that docs/ is under revision control 
(setuptools) or add a "recursive-include docs" to MANIFEST.in 
(distutils).  Then, "setup.py sdist" will build a correct tarball.


From marius at pov.lt  Mon Mar  1 10:30:07 2010
From: marius at pov.lt (Marius Gedminas)
Date: Mon, 1 Mar 2010 11:30:07 +0200
Subject: [Distutils] layout and setup.py for packaging documentation
In-Reply-To: <20100301034925.D37403A40A0@sparrow.telecommunity.com>
References: <b61c19e71002281303s79c55e61u1eef6c82e07796ed@mail.gmail.com>
	<20100228221502.8CCAD3A40A7@sparrow.telecommunity.com>
	<6f4025011002281439t2dda1538gb488e20e0df6cc6c@mail.gmail.com>
	<20100301034925.D37403A40A0@sparrow.telecommunity.com>
Message-ID: <20100301093007.GA8471@fridge.pov.lt>

On Sun, Feb 28, 2010 at 10:49:25PM -0500, P.J. Eby wrote:
> In other words, Jean Daniel should retain his source layout of:
>
>    wordish-1.0.2/
>         setup.py
>         wordish.py
>         docs/
>             index.html
>             command-ref.html
>
> And simply make sure that docs/ is under revision control (setuptools) or 
> add a "recursive-include docs" to MANIFEST.in (distutils).  Then, 
> "setup.py sdist" will build a correct tarball.

Right.

I'd only like to add that the first solution (revision control magic) is
often fragile: revision control metadata format changes (happened with
subversion twice: 1.4 -> 1.5, 1.5 -> 1.6), or you switch revision
control systems (svn -> bzr/hg) and forget to install the appropriate
setuptools plugin, or you need to make a release on a different computer
that happens not to have the appropriate setuptools plugin.  In the end
it's very easy to produce incomplete sdists and not notice that until
it's too late.

I recommend always writing a MANIFEST.in and perhaps implementing some
sort of 'make distcheck' automated test that builds an sdist, extracts
it, builds a second sdist from the first one, then compares the two to
see if any files are missing.

Here's an example of 'make distcheck':
http://bazaar.launchpad.net/~mgedmin/gtimelog/trunk/annotate/head:/Makefile

Please ignore the frothy comment about black magic, I must've been
really frustrated when I wrote it...  Setuptools and the surrounding
ecosystem of packages (PyPI, virtualenv, buildout, pip, Distribute) is
probably the best thing that happened to Python lately, despite
occasional little quirks.

Marius Gedminas
-- 
You've obviously never tried to reverse engineer a chip using an electron
microscope. [...] That's like looking at the grains of sand on a beach
and trying to map out the coastline of Hawaii. -- Cutie Pi, July 2006
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100301/ac693643/attachment.pgp>

From jeandaniel.browne at gmail.com  Mon Mar  1 13:08:51 2010
From: jeandaniel.browne at gmail.com (Jean Daniel)
Date: Mon, 1 Mar 2010 13:08:51 +0100
Subject: [Distutils] layout and setup.py for packaging documentation
In-Reply-To: <94bdd2611002281503s1e747cecp8dca9396dfe62bac@mail.gmail.com>
References: <b61c19e71002281303s79c55e61u1eef6c82e07796ed@mail.gmail.com>
	<20100228221502.8CCAD3A40A7@sparrow.telecommunity.com>
	<6f4025011002281439t2dda1538gb488e20e0df6cc6c@mail.gmail.com>
	<94bdd2611002281503s1e747cecp8dca9396dfe62bac@mail.gmail.com>
Message-ID: <b61c19e71003010408w13e09d0ek649daaa9f9d84186@mail.gmail.com>

> As a matter of fact, we've worked on this during the sprints, and are
> preparing a proposal
> that will let people define a place for doc (and other stuff) and let
> the OS packager decide where
> it lands (with defaults per OS).

I'll read the proposal. I wonder how it is possible to layout a source
tarball with hints to the OS packager on how to do the right thing.
>From what I have seen, there is no really specification or convention
for tagging a directory in a source tarball as 'doc' in a language
agnostic and OS agnostic way.

Does anyone know if the good people form Perl and Ruby have came up
with a good solution?

From ziade.tarek at gmail.com  Mon Mar  1 13:52:19 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 1 Mar 2010 13:52:19 +0100
Subject: [Distutils] layout and setup.py for packaging documentation
In-Reply-To: <b61c19e71003010408w13e09d0ek649daaa9f9d84186@mail.gmail.com>
References: <b61c19e71002281303s79c55e61u1eef6c82e07796ed@mail.gmail.com>
	<20100228221502.8CCAD3A40A7@sparrow.telecommunity.com>
	<6f4025011002281439t2dda1538gb488e20e0df6cc6c@mail.gmail.com>
	<94bdd2611002281503s1e747cecp8dca9396dfe62bac@mail.gmail.com>
	<b61c19e71003010408w13e09d0ek649daaa9f9d84186@mail.gmail.com>
Message-ID: <94bdd2611003010452ib071825uba709f2d45064606@mail.gmail.com>

On Mon, Mar 1, 2010 at 1:08 PM, Jean Daniel <jeandaniel.browne at gmail.com> wrote:
>> As a matter of fact, we've worked on this during the sprints, and are
>> preparing a proposal
>> that will let people define a place for doc (and other stuff) and let
>> the OS packager decide where
>> it lands (with defaults per OS).
>
> I'll read the proposal. I wonder how it is possible to layout a source
> tarball with hints to the OS packager on how to do the right thing.
> From what I have seen, there is no really specification or convention
> for tagging a directory in a source tarball as 'doc' in a language
> agnostic and OS agnostic way.

This is done by describing the content of your source tarball in a
much detailed way than what we have today.

We worked with Fedora+Ubunte ppl on this, and started to specify those
things here:

http://hg.python.org/distutils2/file/cdf2da431e2b/docs/design/wiki.rst

This is a 3 days work during the sprint with 4/5 ppl involved. It also
contains elements from previous works on the topic.

It's a work in progress but you can read it to get an idea on where we
are going.

To roughly summarize the idea, each platform (a platform is a
different os.name value) will have default paths for each location of
a pseudo-FHS that goes further than Python installations locations. So
we include things such as configuration files location, or help files
location, etc...  Then each OS packagers will be able to change these
paths globally from a configuration file. Windows will have dummy
locations.

You, as a developer, will just have to point the location on your
project's tree and tell what kind of file it is, then use an API in
your code to read back the file (wherever it finally lands).

We are working on this proposal to be included in PEP 376, then we
will propose it here at distutils-SIG, for a
round of feedback, rework, etc.

The goal is to see it ready within 5 weeks, (before Python2.7 first
beta). It's a hard goal but if we manage to reach it, it means that I
will be able to change Python's sysconfig module for 2.7 (+pkutil
APIs), and provide a backport of it in distutils2 for people to start
using it.

>
> Does anyone know if the good people form Perl and Ruby have came up
> with a good solution?

As far as I know, there's no such detailed information on Ruby or Perl
land, but I am not an expert -- I just lurked into those worlds.

I do believe that if we finish that proposal and include it, Python
will be the most advanced one on this particular topic compared to
Ruby or Perl.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From sridharr at activestate.com  Mon Mar  1 17:44:06 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 1 Mar 2010 08:44:06 -0800
Subject: [Distutils] layout and setup.py for packaging documentation
In-Reply-To: <94bdd2611003010452ib071825uba709f2d45064606@mail.gmail.com>
References: <b61c19e71002281303s79c55e61u1eef6c82e07796ed@mail.gmail.com>
	<20100228221502.8CCAD3A40A7@sparrow.telecommunity.com>
	<6f4025011002281439t2dda1538gb488e20e0df6cc6c@mail.gmail.com>
	<94bdd2611002281503s1e747cecp8dca9396dfe62bac@mail.gmail.com>
	<b61c19e71003010408w13e09d0ek649daaa9f9d84186@mail.gmail.com>
	<94bdd2611003010452ib071825uba709f2d45064606@mail.gmail.com>
Message-ID: <4D12E395-3C95-4780-8236-46D9CB5F56F9@activestate.com>

Ah, very nice!

This was one of the things I wanted to discuss in the sprints. I've been mentioning this idea internally as well. Having documentation standards would ultimately benefit the user who could thus have a central place on his computer to browse documentation for installed Python packages which packages are installed via easy_install/pip/enstaller/PyPM/etc...

I'm not sure how far this was discussed in the sprints. Is the documentation directory expected to contain files in certain format - for example, with a file describing the Table-of-Contents (toc.xml) that would then be used to render MSDN like doc tree?

-srid

On 2010-03-01, at 4:52 AM, Tarek Ziad? wrote:

> On Mon, Mar 1, 2010 at 1:08 PM, Jean Daniel <jeandaniel.browne at gmail.com> wrote:
>>> As a matter of fact, we've worked on this during the sprints, and are
>>> preparing a proposal
>>> that will let people define a place for doc (and other stuff) and let
>>> the OS packager decide where
>>> it lands (with defaults per OS).
>> 
>> I'll read the proposal. I wonder how it is possible to layout a source
>> tarball with hints to the OS packager on how to do the right thing.
>> From what I have seen, there is no really specification or convention
>> for tagging a directory in a source tarball as 'doc' in a language
>> agnostic and OS agnostic way.
> 
> This is done by describing the content of your source tarball in a
> much detailed way than what we have today.
> 
> We worked with Fedora+Ubunte ppl on this, and started to specify those
> things here:
> 
> http://hg.python.org/distutils2/file/cdf2da431e2b/docs/design/wiki.rst
> 
> This is a 3 days work during the sprint with 4/5 ppl involved. It also
> contains elements from previous works on the topic.
> 
> It's a work in progress but you can read it to get an idea on where we
> are going.
> 
> To roughly summarize the idea, each platform (a platform is a
> different os.name value) will have default paths for each location of
> a pseudo-FHS that goes further than Python installations locations. So
> we include things such as configuration files location, or help files
> location, etc...  Then each OS packagers will be able to change these
> paths globally from a configuration file. Windows will have dummy
> locations.
> 
> You, as a developer, will just have to point the location on your
> project's tree and tell what kind of file it is, then use an API in
> your code to read back the file (wherever it finally lands).
> 
> We are working on this proposal to be included in PEP 376, then we
> will propose it here at distutils-SIG, for a
> round of feedback, rework, etc.
> 
> The goal is to see it ready within 5 weeks, (before Python2.7 first
> beta). It's a hard goal but if we manage to reach it, it means that I
> will be able to change Python's sysconfig module for 2.7 (+pkutil
> APIs), and provide a backport of it in distutils2 for people to start
> using it.
> 
>> 
>> Does anyone know if the good people form Perl and Ruby have came up
>> with a good solution?
> 
> As far as I know, there's no such detailed information on Ruby or Perl
> land, but I am not an expert -- I just lurked into those worlds.
> 
> I do believe that if we finish that proposal and include it, Python
> will be the most advanced one on this particular topic compared to
> Ruby or Perl.
> 
> Regards
> Tarek
> 
> -- 
> Tarek Ziad? | http://ziade.org
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


From sridharr at activestate.com  Mon Mar  1 17:52:41 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 1 Mar 2010 08:52:41 -0800
Subject: [Distutils] layout and setup.py for packaging documentation
In-Reply-To: <4D12E395-3C95-4780-8236-46D9CB5F56F9@activestate.com>
References: <b61c19e71002281303s79c55e61u1eef6c82e07796ed@mail.gmail.com>
	<20100228221502.8CCAD3A40A7@sparrow.telecommunity.com>
	<6f4025011002281439t2dda1538gb488e20e0df6cc6c@mail.gmail.com>
	<94bdd2611002281503s1e747cecp8dca9396dfe62bac@mail.gmail.com>
	<b61c19e71003010408w13e09d0ek649daaa9f9d84186@mail.gmail.com>
	<94bdd2611003010452ib071825uba709f2d45064606@mail.gmail.com>
	<4D12E395-3C95-4780-8236-46D9CB5F56F9@activestate.com>
Message-ID: <B88F45F0-9059-4FE4-9575-2123B1F5A6D7@activestate.com>


On 2010-03-01, at 8:44 AM, Sridhar Ratnakumar wrote:

> Is the documentation directory expected to contain files in certain format - for example, with a file describing the Table-of-Contents (toc.xml) that would then be used to render MSDN like doc tree?

.. and/or make a single-container (eg: CHM[1]) out of it. I guess this feature could be made optional, so developers can include simple docs without having to worry about any mandatory standard, and we could contribute a Sphinx patch to automatically produce toc.xml.

-srid

***
[1] ActivePython already includes extra docs (tutorials, peps. etc..) in a CHM file along with the Python docs

From ziade.tarek at gmail.com  Mon Mar  1 18:17:43 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 1 Mar 2010 18:17:43 +0100
Subject: [Distutils] layout and setup.py for packaging documentation
In-Reply-To: <B88F45F0-9059-4FE4-9575-2123B1F5A6D7@activestate.com>
References: <b61c19e71002281303s79c55e61u1eef6c82e07796ed@mail.gmail.com>
	<20100228221502.8CCAD3A40A7@sparrow.telecommunity.com>
	<6f4025011002281439t2dda1538gb488e20e0df6cc6c@mail.gmail.com>
	<94bdd2611002281503s1e747cecp8dca9396dfe62bac@mail.gmail.com>
	<b61c19e71003010408w13e09d0ek649daaa9f9d84186@mail.gmail.com>
	<94bdd2611003010452ib071825uba709f2d45064606@mail.gmail.com>
	<4D12E395-3C95-4780-8236-46D9CB5F56F9@activestate.com>
	<B88F45F0-9059-4FE4-9575-2123B1F5A6D7@activestate.com>
Message-ID: <94bdd2611003010917m167ac4d9j85723f923af4a601@mail.gmail.com>

On Mon, Mar 1, 2010 at 5:52 PM, Sridhar Ratnakumar
<sridharr at activestate.com> wrote:
>
> On 2010-03-01, at 8:44 AM, Sridhar Ratnakumar wrote:
>
>> Is the documentation directory expected to contain files in certain format - for example, with a file describing the Table-of-Contents (toc.xml) that would then be used to render MSDN like doc tree?
>
> .. and/or make a single-container (eg: CHM[1]) out of it. I guess this feature could be made optional, so developers can include simple docs without having to worry about any mandatory standard, and we could contribute a Sphinx patch to automatically produce toc.xml.
>
> -srid
>
> ***
> [1] ActivePython already includes extra docs (tutorials, peps. etc..) in a CHM file along with the Python docs

We didn't make any assumption on the documentation files format.  But
now that they will be described, you could create a distutils2 command
that generates toc.xml on the fly by reading the list of doc files in
the project (build_msn_doc?)

Another idea that come in my mind also for structurized doc is to use
skeletons when the project is created in the first place. (that's also
a good way to standardize how the community creates its packages)

Sean R. worked on a command called mkpkg that can be used to generate
a distutlils2-based project. It asks a few questions then creates a
setup.py file for you.

Maybe it could be extended to build a pre-generated Sphinx doc
structure, or a CHM-like one. The difficulty is to provide something
that can evolve on its own. Plugins maybe ?

Last, I think that this work could be reunited with the work done in
Distribute's build_doc/upload_doc commands.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From rich at noir.com  Mon Mar  1 19:44:13 2010
From: rich at noir.com (K. Richard Pixley)
Date: Mon, 01 Mar 2010 10:44:13 -0800
Subject: [Distutils] Fwd: The fate of Distutils in Python 2.7
In-Reply-To: <94bdd2611002261352v5dfa8768p7c2bb266efab1272@mail.gmail.com>
References: <94bdd2611002261344q361e702av10fdf99ea5eb9f71@mail.gmail.com>
	<94bdd2611002261352v5dfa8768p7c2bb266efab1272@mail.gmail.com>
Message-ID: <4B8C0AFD.8060604@noir.com>

Tarek Ziad? wrote:
> The rest of the work will happen in distutils2 and we will try to
> release a version asap for Python 2.x and 3.x (2.4 to 3.2), and the
> goal
> is to put it back in the stdlib in Python 3.3
Er... 2.4?  Really?

--rich

From ziade.tarek at gmail.com  Mon Mar  1 20:02:55 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 1 Mar 2010 20:02:55 +0100
Subject: [Distutils] Fwd: The fate of Distutils in Python 2.7
In-Reply-To: <4B8C0AFD.8060604@noir.com>
References: <94bdd2611002261344q361e702av10fdf99ea5eb9f71@mail.gmail.com>
	<94bdd2611002261352v5dfa8768p7c2bb266efab1272@mail.gmail.com>
	<4B8C0AFD.8060604@noir.com>
Message-ID: <94bdd2611003011102h7fc04a32oe4a5e13071c2a5cb@mail.gmail.com>

On Mon, Mar 1, 2010 at 7:44 PM, K. Richard Pixley <rich at noir.com> wrote:
> Tarek Ziad? wrote:
>>
>> The rest of the work will happen in distutils2 and we will try to
>> release a version asap for Python 2.x and 3.x (2.4 to 3.2), and the
>> goal
>> is to put it back in the stdlib in Python 3.3
>
> Er... 2.4? ?Really?

You need 2.3 ?  (please say no !... ;) )


-- 
Tarek Ziad? | http://ziade.org

From rich at noir.com  Mon Mar  1 20:17:56 2010
From: rich at noir.com (K. Richard Pixley)
Date: Mon, 01 Mar 2010 11:17:56 -0800
Subject: [Distutils] Fwd: The fate of Distutils in Python 2.7
In-Reply-To: <94bdd2611003011102h7fc04a32oe4a5e13071c2a5cb@mail.gmail.com>
References: <94bdd2611002261344q361e702av10fdf99ea5eb9f71@mail.gmail.com>	
	<94bdd2611002261352v5dfa8768p7c2bb266efab1272@mail.gmail.com>	
	<4B8C0AFD.8060604@noir.com>
	<94bdd2611003011102h7fc04a32oe4a5e13071c2a5cb@mail.gmail.com>
Message-ID: <4B8C12E4.1030908@noir.com>

Tarek Ziad? wrote:
> On Mon, Mar 1, 2010 at 7:44 PM, K. Richard Pixley <rich at noir.com> wrote:
>   
>> Tarek Ziad? wrote:
>>     
>>> The rest of the work will happen in distutils2 and we will try to
>>> release a version asap for Python 2.x and 3.x (2.4 to 3.2), and the
>>> goal
>>> is to put it back in the stdlib in Python 3.3
>>>       
>> Er... 2.4?  Really?
>>     
> You need 2.3 ?  (please say no !... ;) 
I don't need 2.3.  I don't need 2.4 either.  I was actually wondering if 
the "2.4" was a typo.

It's not clear to me that there's much need for new packaging tools in 
older versions.

--rich

From ziade.tarek at gmail.com  Mon Mar  1 20:22:46 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 1 Mar 2010 20:22:46 +0100
Subject: [Distutils] Fwd: The fate of Distutils in Python 2.7
In-Reply-To: <4B8C12E4.1030908@noir.com>
References: <94bdd2611002261344q361e702av10fdf99ea5eb9f71@mail.gmail.com>
	<94bdd2611002261352v5dfa8768p7c2bb266efab1272@mail.gmail.com>
	<4B8C0AFD.8060604@noir.com>
	<94bdd2611003011102h7fc04a32oe4a5e13071c2a5cb@mail.gmail.com>
	<4B8C12E4.1030908@noir.com>
Message-ID: <94bdd2611003011122x471a4604u4c41fcb26b9cfe84@mail.gmail.com>

On Mon, Mar 1, 2010 at 8:17 PM, K. Richard Pixley <rich at noir.com> wrote:
[..]
>
> I don't need 2.3. ?I don't need 2.4 either. ?I was actually wondering if the
> "2.4" was a typo.
>
> It's not clear to me that there's much need for new packaging tools in older
> versions.

Some people are building new code that needs to work with some
platforms that are requiring 2.5 and sometimes 2.4 (like some old REHL
that are still in use in big companies). I need 2.5 at least myself.

Regards
Tarek

From ziade.tarek at gmail.com  Mon Mar  1 20:26:40 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 1 Mar 2010 20:26:40 +0100
Subject: [Distutils] Fwd: The fate of Distutils in Python 2.7
In-Reply-To: <94bdd2611003011122x471a4604u4c41fcb26b9cfe84@mail.gmail.com>
References: <94bdd2611002261344q361e702av10fdf99ea5eb9f71@mail.gmail.com>
	<94bdd2611002261352v5dfa8768p7c2bb266efab1272@mail.gmail.com>
	<4B8C0AFD.8060604@noir.com>
	<94bdd2611003011102h7fc04a32oe4a5e13071c2a5cb@mail.gmail.com>
	<4B8C12E4.1030908@noir.com>
	<94bdd2611003011122x471a4604u4c41fcb26b9cfe84@mail.gmail.com>
Message-ID: <94bdd2611003011126t290f84b6m727fbeca7b32e593@mail.gmail.com>

On Mon, Mar 1, 2010 at 8:22 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Mon, Mar 1, 2010 at 8:17 PM, K. Richard Pixley <rich at noir.com> wrote:
> [..]
>>
>> I don't need 2.3. ?I don't need 2.4 either. ?I was actually wondering if the
>> "2.4" was a typo.
>>
>> It's not clear to me that there's much need for new packaging tools in older
>> versions.
>
> Some people are building new code that needs to work with some
> platforms that are requiring 2.5 and sometimes 2.4 (like some old REHL
> that are still in use in big companies). I need 2.5 at least myself.

And once you have 2.5 support, 2.4 is not really different. The big
gap is 2.6 because of syntax changes
like "with".

>
> Regards
> Tarek
>



-- 
Tarek Ziad? | http://ziade.org

From fdrake at acm.org  Mon Mar  1 20:27:41 2010
From: fdrake at acm.org (Fred Drake)
Date: Mon, 1 Mar 2010 14:27:41 -0500
Subject: [Distutils] Fwd: The fate of Distutils in Python 2.7
In-Reply-To: <4B8C12E4.1030908@noir.com>
References: <94bdd2611002261344q361e702av10fdf99ea5eb9f71@mail.gmail.com> 
	<94bdd2611002261352v5dfa8768p7c2bb266efab1272@mail.gmail.com> 
	<4B8C0AFD.8060604@noir.com>
	<94bdd2611003011102h7fc04a32oe4a5e13071c2a5cb@mail.gmail.com> 
	<4B8C12E4.1030908@noir.com>
Message-ID: <9cee7ab81003011127o2f41a0d3mc88a037d9efa1957@mail.gmail.com>

On Mon, Mar 1, 2010 at 2:17 PM, K. Richard Pixley <rich at noir.com> wrote:
> It's not clear to me that there's much need for new packaging tools in older
> versions.

I've certainly found it useful to use distribute under Python 2.4.
There are still a lot of people using Python 2.4.

I think the general rule for packaging tools is that you want one that
supports all the versions of Python you're using.  Given that there
are good reasons to try again, it's reasonable to support 2.4.

Migrating to newer versions can take a significant transition period
for some applications.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From chris at simplistix.co.uk  Mon Mar  1 20:22:18 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 01 Mar 2010 19:22:18 +0000
Subject: [Distutils] RFC: Barely minimal CI + tests + packaging in
 Python WAS: Guidelines for where to put tests & how to package them
In-Reply-To: <20100225170007.3A66D3A406A@sparrow.telecommunity.com>
References: <24ea26601002250741n1c42b271oc96b7466853bd970@mail.gmail.com>
	<20100225170007.3A66D3A406A@sparrow.telecommunity.com>
Message-ID: <4B8C13EA.3010100@simplistix.co.uk>

P.J. Eby wrote:
> At 10:41 AM 2/25/2010 -0500, Olemis Lang wrote:
>> PS: BTW, how could I trigger easy_install(ation) at a given point
>> while implementing a distutils command, and let the command perform
>> further actions if deps are installed correctly ?
> 
> Setuptools' "Distribution" object has a method for fetching 
> dependencies.  See setuptools' "test" command for an example.  (This 
> doesn't install the dependencies globally, just drops eggs into the 
> build directory.  But they're there and available to be reused for 
> installation in a later phase, under normal circumstances.)

...which is all pretty grim. If you use this with other packaging tools, 
like, say, buildout, the testing dependencies just get dumped into your 
buildout, which is a bit yucky to put it mildly.

How about putting them where other eggs get put but only making them 
available for the tests?

Failing that, how about putting them somewhere temporary?

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk


From fuzzyman at voidspace.org.uk  Mon Mar  1 20:43:31 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 01 Mar 2010 19:43:31 +0000
Subject: [Distutils] [TIP] RFC: Barely minimal CI + tests + packaging in
 Python WAS: Guidelines for where to put tests & how to package them
In-Reply-To: <4B8C13EA.3010100@simplistix.co.uk>
References: <24ea26601002250741n1c42b271oc96b7466853bd970@mail.gmail.com>	<20100225170007.3A66D3A406A@sparrow.telecommunity.com>
	<4B8C13EA.3010100@simplistix.co.uk>
Message-ID: <4B8C18E3.6000505@voidspace.org.uk>

On 01/03/2010 19:22, Chris Withers wrote:
> P.J. Eby wrote:
>> At 10:41 AM 2/25/2010 -0500, Olemis Lang wrote:
>>> PS: BTW, how could I trigger easy_install(ation) at a given point
>>> while implementing a distutils command, and let the command perform
>>> further actions if deps are installed correctly ?
>>
>> Setuptools' "Distribution" object has a method for fetching 
>> dependencies. See setuptools' "test" command for an example. (This 
>> doesn't install the dependencies globally, just drops eggs into the 
>> build directory. But they're there and available to be reused for 
>> installation in a later phase, under normal circumstances.)
>
> ...which is all pretty grim. If you use this with other packaging 
> tools, like, say, buildout, the testing dependencies just get dumped 
> into your buildout, which is a bit yucky to put it mildly.
>
> How about putting them where other eggs get put but only making them 
> available for the tests?
>
> Failing that, how about putting them somewhere temporary?

For distutils 2 / distribute I think the idea is something along the 
lines of:

There will be a Test-Requires-Dist (or equivalent) field for specifying 
test dependencies - still to be confirmed

distutils2 by default won't install any dependencies for you - so 
neither "setup.py install" nor "setup.py test" will install test 
dependencies

distribute will install standard dependencies but not test dependencies 
by default

with distribute "setup.py test" will *not* install test dependencies - 
there will be a new parameter for install to tell it to fetch test 
dependencies (if necessary)

This is all still subject to discussion and really belongs on the 
distutils mailing list rather than here. It may be possible for 
"setup.py test" with distribute to have another parameter telling it to 
install test dependencies temporarily and then uninstall them afterwards...

All the best,

Michael

>
> Chris
>


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.



From olemis at gmail.com  Mon Mar  1 20:47:18 2010
From: olemis at gmail.com (Olemis Lang)
Date: Mon, 1 Mar 2010 14:47:18 -0500
Subject: [Distutils] RFC: Barely minimal CI + tests + packaging in
	Python WAS: Guidelines for where to put tests & how to package them
In-Reply-To: <4B8C13EA.3010100@simplistix.co.uk>
References: <24ea26601002250741n1c42b271oc96b7466853bd970@mail.gmail.com>
	<20100225170007.3A66D3A406A@sparrow.telecommunity.com>
	<4B8C13EA.3010100@simplistix.co.uk>
Message-ID: <24ea26601003011147k9e1910bpf79758d32ba34750@mail.gmail.com>

On Mon, Mar 1, 2010 at 2:22 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> P.J. Eby wrote:
>>
>> At 10:41 AM 2/25/2010 -0500, Olemis Lang wrote:
>>>
>>> PS: BTW, how could I trigger easy_install(ation) at a given point
>>> while implementing a distutils command, and let the command perform
>>> further actions if deps are installed correctly ?
>>
>> Setuptools' "Distribution" object has a method for fetching dependencies.
>> ?See setuptools' "test" command for an example. ?(This doesn't install the
>> dependencies globally, just drops eggs into the build directory. ?But
>> they're there and available to be reused for installation in a later phase,
>> under normal circumstances.)
>
> ...which is all pretty grim. If you use this with other packaging tools,
> like, say, buildout, the testing dependencies just get dumped into your
> buildout, which is a bit yucky to put it mildly.
>
> How about putting them where other eggs get put but only making them
> available for the tests?
>

something like develop ?

> Failing that, how about putting them somewhere temporary?
>

I am not sure but I think there's an option to specify the build
directory (CMIIW). AFAIK (not tested ;o) what happens is that build
command is executed so I suppose that if options are specified for
this command then it should be parse, accept and use the target dir,
isn't it ?

{{{
$ python setup.py --help build
Common commands: (see '--help-commands' for more)

[...]

Global options:
[...]

Options for 'build' command:
[...]
  --build-temp (-t)  temporary build directory
[...]
}}}

PS: just a comment, but I'd really wanna know if I'm wrong because I
wanted to try something similar @ testrun.org in order to perform
concurrent builds ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

From olemis at gmail.com  Mon Mar  1 20:53:24 2010
From: olemis at gmail.com (Olemis Lang)
Date: Mon, 1 Mar 2010 14:53:24 -0500
Subject: [Distutils] RFC: Barely minimal CI + tests + packaging in
	Python WAS: Guidelines for where to put tests & how to package them
In-Reply-To: <24ea26601003011147k9e1910bpf79758d32ba34750@mail.gmail.com>
References: <24ea26601002250741n1c42b271oc96b7466853bd970@mail.gmail.com>
	<20100225170007.3A66D3A406A@sparrow.telecommunity.com>
	<4B8C13EA.3010100@simplistix.co.uk>
	<24ea26601003011147k9e1910bpf79758d32ba34750@mail.gmail.com>
Message-ID: <24ea26601003011153i2d1f759al75d437657133d410@mail.gmail.com>

On Mon, Mar 1, 2010 at 2:47 PM, Olemis Lang <olemis at gmail.com> wrote:
> On Mon, Mar 1, 2010 at 2:22 PM, Chris Withers <chris at simplistix.co.uk> wrote:
>> P.J. Eby wrote:
>>>
>>> At 10:41 AM 2/25/2010 -0500, Olemis Lang wrote:
>>>>
>>>> PS: BTW, how could I trigger easy_install(ation) at a given point
>>>> while implementing a distutils command, and let the command perform
>>>> further actions if deps are installed correctly ?
>>>
>>> Setuptools' "Distribution" object has a method for fetching dependencies.
>>> ?See setuptools' "test" command for an example. ?(This doesn't install the
>>> dependencies globally, just drops eggs into the build directory. ?But
>>> they're there and available to be reused for installation in a later phase,
>>> under normal circumstances.)
>>
>> ...which is all pretty grim. If you use this with other packaging tools,
>> like, say, buildout, the testing dependencies just get dumped into your
>> buildout, which is a bit yucky to put it mildly.
>>
>> How about putting them where other eggs get put but only making them
>> available for the tests?
>>
>
> something like develop ?
>
>> Failing that, how about putting them somewhere temporary?
>>
>
> I am not sure but I think there's an option to specify the build
> directory (CMIIW). AFAIK (not tested ;o) what happens is that build
> command is executed so I suppose that if options are specified for
> this command then it should be parse, accept and use the target dir,
> isn't it ?
>
> {{{
> $ python setup.py --help build
> Common commands: (see '--help-commands' for more)
>
> [...]
>
> Global options:
> [...]
>
> Options for 'build' command:
> [...]
> ?--build-temp (-t) ?temporary build directory
> [...]
> }}}
>
> PS: just a comment, but I'd really wanna know if I'm wrong because I
> wanted to try something similar @ testrun.org in order to perform
> concurrent builds ;o)
>

I'll be using this plus `virtualenv` (already setup @ testrun.org) in
order to install test dependencies to an isolated (clean ?) Py
environment

;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

From pje at telecommunity.com  Mon Mar  1 20:54:19 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 01 Mar 2010 14:54:19 -0500
Subject: [Distutils] RFC: Barely minimal CI + tests + packaging in
 Python WAS: Guidelines for where to put tests & how to package them
In-Reply-To: <4B8C13EA.3010100@simplistix.co.uk>
References: <24ea26601002250741n1c42b271oc96b7466853bd970@mail.gmail.com>
	<20100225170007.3A66D3A406A@sparrow.telecommunity.com>
	<4B8C13EA.3010100@simplistix.co.uk>
Message-ID: <20100301195412.BC1053A40A7@sparrow.telecommunity.com>

At 07:22 PM 3/1/2010 +0000, Chris Withers wrote:
>P.J. Eby wrote:
>>At 10:41 AM 2/25/2010 -0500, Olemis Lang wrote:
>>>PS: BTW, how could I trigger easy_install(ation) at a given point
>>>while implementing a distutils command, and let the command perform
>>>further actions if deps are installed correctly ?
>>Setuptools' "Distribution" object has a method for fetching 
>>dependencies.  See setuptools' "test" command for an 
>>example.  (This doesn't install the dependencies globally, just 
>>drops eggs into the build directory.  But they're there and 
>>available to be reused for installation in a later phase, under 
>>normal circumstances.)
>
>...which is all pretty grim. If you use this with other packaging 
>tools, like, say, buildout, the testing dependencies just get dumped 
>into your buildout, which is a bit yucky to put it mildly.
>
>How about putting them where other eggs get put but only making them 
>available for the tests?
>
>Failing that, how about putting them somewhere temporary?

They *are* somewhere temporary.  Buildout's not going to install them 
from the setup.py directory, and neither will anything else.


From janssen at parc.com  Tue Mar  2 18:56:46 2010
From: janssen at parc.com (Bill Janssen)
Date: Tue, 2 Mar 2010 09:56:46 PST
Subject: [Distutils] setuptools doesn't seem to know about lib64 on Ubuntu
Message-ID: <56672.1267552606@parc.com>

Hi.  I'm trying to install setuptools on a Ubuntu 9.10 system (64-bit),
in a custom location:

  % python setup.py install --install-layout=deb --prefix=/opt/uplib-1.7.9
  running install
  Checking .pth file support in /opt/uplib-1.7.9/lib/python2.6/dist-packages/
  error: can't create or remove files in install directory

  The following error occurred while trying to add or remove files in the
  installation directory:

      [Errno 2] No such file or directory: '/opt/uplib-1.7.9/lib/python2.6/dist-packages/test-easy-install-10270.pth'

  The installation directory you specified (via --install-dir, --prefix, or
  the distutils default setting) was:

      /opt/uplib-1.7.9/lib/python2.6/dist-packages/

  This directory does not currently exist.  Please create it and try again, or
  choose a different installation directory (using the -d or --install-dir
  option).

  % 

The problem is that it should be looking at 

    /opt/uplib-1.7.9/lib64/python2.6/dist-packages/

which *does* exist, and *is* on the PYTHONPATH.  Is there some way I can
force this via a commandline option?

Bill

From somekool at gmail.com  Tue Mar  2 20:52:24 2010
From: somekool at gmail.com (Mathieu Jobin)
Date: Tue, 2 Mar 2010 14:52:24 -0500
Subject: [Distutils] trouble building setuptools on centos 3.8
Message-ID: <78181ce61003021152s5f331f83i40cd2a249980f2d0@mail.gmail.com>

maybe you can help me. there is something wrong with building this rpm
package ?

maybe because I am running ....

Python 2.2.3 (#1, May  1 2006, 12:33:49)

-rwxrwxr-x pje/pje         277 2006-09-20 17:05:03
setuptools-0.6c11/setuptools/command/register.py
-rw-rw-r-- pje/pje        4442 2008-02-15 12:29:24
setuptools-0.6c11/setuptools/command/test.py
-rwxrwxr-x pje/pje       28275 2009-10-19 13:35:44
setuptools-0.6c11/setuptools/package_index.py
-rwxrwxr-x pje/pje        7168 2009-10-19 17:18:57
setuptools-0.6c11/setuptools/gui.exe
+ STATUS=0

+ '[' 0 -ne 0 ']'

+ cd setuptools-0.6c11

++ /usr/bin/id -u

+ '[' 0 = 0 ']'

+ /bin/chown -Rhf root .

++ /usr/bin/id -u

+ '[' 0 = 0 ']'

+ /bin/chgrp -Rhf root .

+ /bin/chmod -Rf a+rX,g-w,o-w .

+ exit 0

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.92516

+ umask 022

+ cd /usr/src/redhat/BUILD

+ cd setuptools-0.6c11

+ python setup.py build

setuptools/dist.py:661: Warning: 'yield' will become a reserved keyword in
the future
Traceback (most recent call last):

  File "setup.py", line 12, in ?

    from setuptools import setup, find_packages

  File "setuptools/__init__.py", line 2, in ?

    from setuptools.extension import Extension, Library

  File "setuptools/extension.py", line 2, in ?

    from dist import _get_unpatched

  File "setuptools/dist.py", line 661

    yield pkg

            ^

SyntaxError: invalid syntax

error: Bad exit status from /var/tmp/rpm-tmp.92516 (%build)



RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.92516 (%build)
Failed to build package setuptools.spec.
[root at qcsmbs1004 SPECS]#

any idea ?

thanks

-- 
Go is to Western chess what philosophy is to double entry accounting.
- From Shibumi, bestseller by Trevanian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100302/3e05b5fc/attachment.html>

From WCoole at aperiogroup.com  Tue Mar  2 22:22:55 2010
From: WCoole at aperiogroup.com (Walter Coole)
Date: Tue, 2 Mar 2010 13:22:55 -0800
Subject: [Distutils] Newby Question: install easy_install for python2.5 on
	RHEL
Message-ID: <55AD1EEF173837488F4B56BEFC99B71C41D02D@server.aperiogroup.local>

When I try to install with:

 

                sudo sh setuptools-0.6c11-py2.5.egg

 

I get an error:

 

                error: invalid Python installation: unable to open
/usr/lib64/python2.5/config/Makefile (No such file or directory)

 

That I don't really understand.  Yes, it's true that there is no
/usr/lib64/python2.5/config directory, but I've gotten along nicely
without one for quite a while.

 

I haven't had much trouble with my Fedora box (which uses 2.5 by
default) or the default 2.4 installation on my RHEL (which doesn't help,
since my application needs 2.5), so I started thinking I knew what I was
doing.

 

I'm sure that there is some confusion due to the fact that I've
installed python2.5 in a different-than-usual directory.  I need to keep
"python" referring to python2.4, since RHEL 5.2 depends on it.
Presumably, if I can tell setuptools-0.6c11-py2.5.egg enough about where
things are, it should be able to adapt.

 

I've tried several variations, but haven't made much progress.   If
anyone could point out which option to use to override its choice of
directory or which directory to point it to, that would be a big help.

 

Or perhaps I've just been looking at this completely wrong-headedly, in
which case I'd be most grateful for instructions on how to install some
variation of setuptools to work with python2.5 on a RHEL 5 system.

 

Thanks!

Walter

 

PS. In case it matters to anyone, all I really need to do is to install
the beatbox module, for which I have the .egg file, but I don't know how
to install a .egg file in a useful way without setuptools or some such.
It seem a shame to break open the egg and install its guts manually, but
if that seems like the available alternative, I'd welcome any pointers.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100302/c5745e10/attachment.html>

From zubin.mithra at gmail.com  Wed Mar  3 04:40:32 2010
From: zubin.mithra at gmail.com (Zubin Mithra)
Date: Wed, 3 Mar 2010 09:10:32 +0530
Subject: [Distutils] (no subject)
Message-ID: <8e7c74321003021940p5ee11843x43ceed1262878300@mail.gmail.com>

Hello,

I`d like to work on distutils as part of GSoC 2010. Could you please
help me, on as to when the ideas list for python distutils might be
put up?

Thank you,
Zubin Mithra

From jvporter at wisc.edu  Wed Mar  3 05:30:38 2010
From: jvporter at wisc.edu (James Porter)
Date: Tue, 02 Mar 2010 22:30:38 -0600
Subject: [Distutils] Installing header files with setuptools
Message-ID: <hmkoll$ldo$2@dough.gmane.org>

Perhaps this is a bug or perhaps I'm just doing it wrong, but I can't 
figure out a good way to install C header files as part of a setuptools 
project.

With distutils, there's a "headers" argument to setup() that installs 
the header files in their proper spot, but setuptools ignores this. It 
looks like setuptools is hijacking the install command and manually 
running install_lib, install_data, etc, but never install_headers.

Does setuptools expect me to do this in a different way, or is this 
something that should be fixed?

- Jim


From pje at telecommunity.com  Wed Mar  3 07:02:36 2010
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 03 Mar 2010 01:02:36 -0500
Subject: [Distutils] Installing header files with setuptools
In-Reply-To: <hmkoll$ldo$2@dough.gmane.org>
References: <hmkoll$ldo$2@dough.gmane.org>
Message-ID: <20100303060234.9BB323A4077@sparrow.telecommunity.com>

At 11:30 PM 3/2/2010, James Porter wrote:
>Perhaps this is a bug or perhaps I'm just doing it wrong, but I 
>can't figure out a good way to install C header files as part of a 
>setuptools project.
>
>With distutils, there's a "headers" argument to setup() that 
>installs the header files in their proper spot, but setuptools 
>ignores this. It looks like setuptools is hijacking the install 
>command and manually running install_lib, install_data, etc, but 
>never install_headers.

Egg-based installs don't include headers.  However, if you use the 
--root or --single-version-externally-managed options to "setup.py 
install", a backwards-compatible, non-egg-based installation is done, 
and the headers should be included in that case.  This installation 
mode is used by default when building other types of binary 
distribution, such as RPMs.


From optilude+lists at gmail.com  Wed Mar  3 07:36:17 2010
From: optilude+lists at gmail.com (Martin Aspeli)
Date: Wed, 03 Mar 2010 14:36:17 +0800
Subject: [Distutils] zc.buildout - macros extending macros
Message-ID: <hml013$5uu$1@dough.gmane.org>

Hi,

Possibly related to my earlier email about the ordering of extends 
lines, but also possibly a bug or missing feature:

I have a buildout.cfg that extends instance.cfg and prod.cfg:

[buildout]
extends = instance.cfg prod.cfg

In instance.cfg, I have:

[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
...

In prod.cfg:

[prod-instance]
<= instance
debug-mode = off
cache-size = 10000

[instance1]
<= prod-instance
http-address = 8001

[instance2]
<= prod-instance
http-address = 8002

The idea is that shared instance settings (which are also used in a 
debug.cfg) are kept in [instance], but ones specific to the production 
server are kept in [prod-instance], and instance1...N are clones of the 
prod-instance that only vary the port.

Unfortunately, the options from [instance] don't seem to make it into 
[instance1] or [instance2]. In other words, the macro doesn't seem to be 
evaluated "transitively".

Am I doing something wrong, or is this just not supported?

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


From jvporter at wisc.edu  Wed Mar  3 08:39:27 2010
From: jvporter at wisc.edu (James Porter)
Date: Wed, 03 Mar 2010 01:39:27 -0600
Subject: [Distutils] Installing header files with setuptools
In-Reply-To: <20100303060234.9BB323A4077@sparrow.telecommunity.com>
References: <hmkoll$ldo$2@dough.gmane.org>
	<20100303060234.9BB323A4077@sparrow.telecommunity.com>
Message-ID: <hml3nm$fb7$1@dough.gmane.org>

On 3/3/2010 12:02 AM, Phillip J. Eby wrote:
> Egg-based installs don't include headers. However, if you use the --root
> or --single-version-externally-managed options to "setup.py install", a
> backwards-compatible, non-egg-based installation is done, and the
> headers should be included in that case. This installation mode is used
> by default when building other types of binary distribution, such as RPMs.

Hm. In that case, is there an easy way to get install_headers to run 
when installing via easy_install (or pip) *without* passing special 
arguments to it?

Ideally I'd like to use the module as the basis for other C extension 
modules and have source compilation via easy_install/pip "just work". 
Right now I just have a duplicate of the headers in the dependent 
project, but that seems somewhat hackish.

Nevertheless, at least it's encouraging to know what's really going on. 
Thanks.

- Jim


From ziade.tarek at gmail.com  Wed Mar  3 09:52:59 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 3 Mar 2010 09:52:59 +0100
Subject: [Distutils] (no subject)
In-Reply-To: <8e7c74321003021940p5ee11843x43ceed1262878300@mail.gmail.com>
References: <8e7c74321003021940p5ee11843x43ceed1262878300@mail.gmail.com>
Message-ID: <94bdd2611003030052k60e0cbf7l379488a5d4b0b7f4@mail.gmail.com>

On Wed, Mar 3, 2010 at 4:40 AM, Zubin Mithra <zubin.mithra at gmail.com> wrote:
> Hello,
>
> I`d like to work on distutils as part of GSoC 2010. Could you please
> help me, on as to when the ideas list for python distutils might be
> put up?

Hello,

I am planning to add a topic on distutils2 this week, I'll let you
know here when it's up and when students may apply

Regards
Tarek

>
> Thank you,
> Zubin Mithra
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From hanno at hannosch.eu  Wed Mar  3 10:28:04 2010
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Wed, 3 Mar 2010 10:28:04 +0100
Subject: [Distutils] zc.buildout - macros extending macros
In-Reply-To: <hml013$5uu$1@dough.gmane.org>
References: <hml013$5uu$1@dough.gmane.org>
Message-ID: <5cae42b21003030128v24f17c3erb14cda84fe1c1d8f@mail.gmail.com>

On Wednesday, March 3, 2010, Martin Aspeli <optilude+lists at gmail.com> wrote:
[...]
> Unfortunately, the options from [instance] don't seem to make it into [instance1] or [instance2]. In other words, the macro doesn't seem to be evaluated "transitively".
>
> Am I doing something wrong, or is this just not supported?

This is just not supported at the moment. Macros don't work recursively.

Hanno

From carl at dirtcircle.com  Wed Mar  3 14:41:59 2010
From: carl at dirtcircle.com (Carl Meyer)
Date: Wed, 03 Mar 2010 08:41:59 -0500
Subject: [Distutils] Installing header files with setuptools
In-Reply-To: <hml3nm$fb7$1@dough.gmane.org>
References: <hmkoll$ldo$2@dough.gmane.org>	<20100303060234.9BB323A4077@sparrow.telecommunity.com>
	<hml3nm$fb7$1@dough.gmane.org>
Message-ID: <4B8E6727.4080903@dirtcircle.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Porter wrote:
> Hm. In that case, is there an easy way to get install_headers to run
> when installing via easy_install (or pip) *without* passing special
> arguments to it?

Have you tried pip? Pip always uses --single-version-externally-managed,
so if what Phillip says is correct, I would expect it to already just work.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAkuOZyYACgkQ1j/fhc23WEBAdwCgqYGL947f8oziQxeN7TuT0ITg
o1cAmJyYT8iYFd/5Ktpp6vAvJqc0LVo=
=9JBi
-----END PGP SIGNATURE-----

From janssen at parc.com  Wed Mar  3 19:26:23 2010
From: janssen at parc.com (Bill Janssen)
Date: Wed, 3 Mar 2010 10:26:23 PST
Subject: [Distutils] Newby Question: install easy_install for python2.5
	on RHEL
In-Reply-To: <55AD1EEF173837488F4B56BEFC99B71C41D02D@server.aperiogroup.local>
References: <55AD1EEF173837488F4B56BEFC99B71C41D02D@server.aperiogroup.local>
Message-ID: <93359.1267640783@parc.com>

Walter Coole <WCoole at aperiogroup.com> wrote:

> When I try to install with:
> 
>  
> 
>                 sudo sh setuptools-0.6c11-py2.5.egg

Walter, I believe you want

          sudo sh setuptools-0.6c11-py2.5.egg --install-dir MYDIR

which tells it exactly where to put the setuptools package.

Bill

> 
>  
> 
> I get an error:
> 
>  
> 
>                 error: invalid Python installation: unable to open
> /usr/lib64/python2.5/config/Makefile (No such file or directory)
> 
>  
> 
> That I don't really understand.  Yes, it's true that there is no
> /usr/lib64/python2.5/config directory, but I've gotten along nicely
> without one for quite a while.
> 
>  
> 
> I haven't had much trouble with my Fedora box (which uses 2.5 by
> default) or the default 2.4 installation on my RHEL (which doesn't help,
> since my application needs 2.5), so I started thinking I knew what I was
> doing.
> 
>  
> 
> I'm sure that there is some confusion due to the fact that I've
> installed python2.5 in a different-than-usual directory.  I need to keep
> "python" referring to python2.4, since RHEL 5.2 depends on it.
> Presumably, if I can tell setuptools-0.6c11-py2.5.egg enough about where
> things are, it should be able to adapt.
> 
>  
> 
> I've tried several variations, but haven't made much progress.   If
> anyone could point out which option to use to override its choice of
> directory or which directory to point it to, that would be a big help.
> 
>  
> 
> Or perhaps I've just been looking at this completely wrong-headedly, in
> which case I'd be most grateful for instructions on how to install some
> variation of setuptools to work with python2.5 on a RHEL 5 system.
> 
>  
> 
> Thanks!
> 
> Walter
> 
>  
> 
> PS. In case it matters to anyone, all I really need to do is to install
> the beatbox module, for which I have the .egg file, but I don't know how
> to install a .egg file in a useful way without setuptools or some such.
> It seem a shame to break open the egg and install its guts manually, but
> if that seems like the available alternative, I'd welcome any pointers.
> 
>  
> 
>  
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

From carl at dirtcircle.com  Wed Mar  3 23:30:03 2010
From: carl at dirtcircle.com (Carl Meyer)
Date: Wed, 03 Mar 2010 17:30:03 -0500
Subject: [Distutils] Installing header files with setuptools
In-Reply-To: <1267654714.2018.82.camel@widdershins>
References: <hmkoll$ldo$2@dough.gmane.org>
	<20100303060234.9BB323A4077@sparrow.telecommunity.com>
	<hml3nm$fb7$1@dough.gmane.org> <4B8E6727.4080903@dirtcircle.com>
	<1267654714.2018.82.camel@widdershins>
Message-ID: <4B8EE2EB.6060206@dirtcircle.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Porter wrote:
> This works, but it installs the headers in a surprising place. With the
> "prefix" scheme, the headers end up in `pwd`/lib/include. With the
> "home" scheme, the headers end up in <home>/lib/python/lib/include.
> 
> In either case I'd expect them to end up in <home-or-prefix>/include (or
> something like that anyway). I'd *certainly* expect the prefix scheme
> not to install the headers outside of the prefix.
> 
> The issue, it seems, is a workaround for virtualenv in pip/req.py:
> <http://hg.notalon.org/ianb/pip/src/tip/pip/req.py#cl-515>. Since I'm
> not actually using virtualenv, I don't know exactly what would happen
> with that, but if there's a workaround for virtualenv, shouldn't it only
> be activated when virtualenv is in use? Not that I know how to detect
> that. :)

Yeah, that does appear to be a bug in pip, I've reported it at
http://bitbucket.org/ianb/pip/issue/73/header-files-installed-to-wrong-location.
And I think you have the right fix, too; that header location hack
should only happen if actually inside a virtualenv. Shouldn't be a hard
fix. Is your package publicly available? I don't have anything on hand
that installs header files to test the fix with.

BTW, the best way I know of to check for "am I in a virtualenv?" is to
check for the existence of sys.real_prefix.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuO4usACgkQ1j/fhc23WEB74QCdGwJslblzsTKIjRrxQUZBL8tO
BZYAni3OGpadrKi5nidV5zKZI1xZ/+A0
=Pn0u
-----END PGP SIGNATURE-----

From WCoole at aperiogroup.com  Wed Mar  3 20:36:43 2010
From: WCoole at aperiogroup.com (Walter Coole)
Date: Wed, 3 Mar 2010 11:36:43 -0800
Subject: [Distutils] Newby Question: install easy_install for python2.5
	on RHEL
In-Reply-To: <93359.1267640783@parc.com>
References: <55AD1EEF173837488F4B56BEFC99B71C41D02D@server.aperiogroup.local>
	<93359.1267640783@parc.com>
Message-ID: <55AD1EEF173837488F4B56BEFC99B71C41D0BA@server.aperiogroup.local>

Perhaps I don't know enough to pick the right value for MYDIR.  Since my
Fedora box has it at /usr/lib/python2.5/site-packages/setuptools/ and
the 2.4 version is at
/usr/lib/python2.4/site-packages/setuptools-0.6c11-py2.4.egg/, I
figured:

	sudo sh setuptools-0.6c11-py2.5.egg --install-dir
/usr/lib/python2.5/site-packages

would work, but I get the same error:

	error: invalid Python installation: unable to open
/usr/lib64/python2.5/config/Makefile (No such file or directory)

Any thoughts on what MYDIR should be?

Thanks!
Walter


-----Original Message-----
From: Bill Janssen [mailto:janssen at parc.com] 
Sent: Wednesday, March 03, 2010 10:26 AM
To: Walter Coole
Cc: distutils-sig at python.org; janssen at parc.com
Subject: Re: [Distutils] Newby Question: install easy_install for
python2.5 on RHEL

Walter Coole <WCoole at aperiogroup.com> wrote:

> When I try to install with:
> 
>  
> 
>                 sudo sh setuptools-0.6c11-py2.5.egg

Walter, I believe you want

          sudo sh setuptools-0.6c11-py2.5.egg --install-dir MYDIR

which tells it exactly where to put the setuptools package.

Bill

> 
>  
> 
> I get an error:
> 
>  
> 
>                 error: invalid Python installation: unable to open
> /usr/lib64/python2.5/config/Makefile (No such file or directory)
> 
>  
> 
> That I don't really understand.  Yes, it's true that there is no
> /usr/lib64/python2.5/config directory, but I've gotten along nicely
> without one for quite a while.
> 
>  
> 
> I haven't had much trouble with my Fedora box (which uses 2.5 by
> default) or the default 2.4 installation on my RHEL (which doesn't
help,
> since my application needs 2.5), so I started thinking I knew what I
was
> doing.
> 
>  
> 
> I'm sure that there is some confusion due to the fact that I've
> installed python2.5 in a different-than-usual directory.  I need to
keep
> "python" referring to python2.4, since RHEL 5.2 depends on it.
> Presumably, if I can tell setuptools-0.6c11-py2.5.egg enough about
where
> things are, it should be able to adapt.
> 
>  
> 
> I've tried several variations, but haven't made much progress.   If
> anyone could point out which option to use to override its choice of
> directory or which directory to point it to, that would be a big help.
> 
>  
> 
> Or perhaps I've just been looking at this completely wrong-headedly,
in
> which case I'd be most grateful for instructions on how to install
some
> variation of setuptools to work with python2.5 on a RHEL 5 system.
> 
>  
> 
> Thanks!
> 
> Walter
> 
>  
> 
> PS. In case it matters to anyone, all I really need to do is to
install
> the beatbox module, for which I have the .egg file, but I don't know
how
> to install a .egg file in a useful way without setuptools or some
such.
> It seem a shame to break open the egg and install its guts manually,
but
> if that seems like the available alternative, I'd welcome any
pointers.
> 
>  
> 
>  
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig



From jvporter at wisc.edu  Wed Mar  3 23:57:11 2010
From: jvporter at wisc.edu (James Porter)
Date: Wed, 03 Mar 2010 16:57:11 -0600
Subject: [Distutils] Installing header files with setuptools
In-Reply-To: <4B8EE2EB.6060206@dirtcircle.com>
References: <hmkoll$ldo$2@dough.gmane.org>
	<20100303060234.9BB323A4077@sparrow.telecommunity.com>
	<hml3nm$fb7$1@dough.gmane.org> <4B8E6727.4080903@dirtcircle.com>
	<1267654714.2018.82.camel@widdershins>
	<4B8EE2EB.6060206@dirtcircle.com>
Message-ID: <1267657031.2018.107.camel@widdershins>

On Wed, 2010-03-03 at 17:30 -0500, Carl Meyer wrote:
> Yeah, that does appear to be a bug in pip, I've reported it at
> http://bitbucket.org/ianb/pip/issue/73/header-files-installed-to-wrong-location.
> And I think you have the right fix, too; that header location hack
> should only happen if actually inside a virtualenv. Shouldn't be a hard
> fix. Is your package publicly available? I don't have anything on hand
> that installs header files to test the fix with.

My package is publically available here
<http://pypi.python.org/pypi/PyTAPS/>, but that's probably not all that
helpful in practice, since it has a fair number of C dependencies. For
simplicity, I made an incredibly simple package (all it installs is a
single header file) that reproduces the problem for me, which you can
get via: 

pip install -f
https://mywebspace.wisc.edu/jvporter/web/header_test-1.0.tar.gz
header_test

- Jim


From jvporter at wisc.edu  Wed Mar  3 23:18:34 2010
From: jvporter at wisc.edu (James Porter)
Date: Wed, 03 Mar 2010 16:18:34 -0600
Subject: [Distutils] Installing header files with setuptools
In-Reply-To: <4B8E6727.4080903@dirtcircle.com>
References: <hmkoll$ldo$2@dough.gmane.org>
	<20100303060234.9BB323A4077@sparrow.telecommunity.com>
	<hml3nm$fb7$1@dough.gmane.org> <4B8E6727.4080903@dirtcircle.com>
Message-ID: <1267654714.2018.82.camel@widdershins>

On Wed, 2010-03-03 at 08:41 -0500, Carl Meyer wrote:
> James Porter wrote:
> > Hm. In that case, is there an easy way to get install_headers to run
> > when installing via easy_install (or pip) *without* passing special
> > arguments to it?
> 
> Have you tried pip? Pip always uses --single-version-externally-managed,
> so if what Phillip says is correct, I would expect it to already just work.

This works, but it installs the headers in a surprising place. With the
"prefix" scheme, the headers end up in `pwd`/lib/include. With the
"home" scheme, the headers end up in <home>/lib/python/lib/include.

In either case I'd expect them to end up in <home-or-prefix>/include (or
something like that anyway). I'd *certainly* expect the prefix scheme
not to install the headers outside of the prefix.

The issue, it seems, is a workaround for virtualenv in pip/req.py:
<http://hg.notalon.org/ianb/pip/src/tip/pip/req.py#cl-515>. Since I'm
not actually using virtualenv, I don't know exactly what would happen
with that, but if there's a workaround for virtualenv, shouldn't it only
be activated when virtualenv is in use? Not that I know how to detect
that. :)

- Jim


From manlio.perillo at gmail.com  Thu Mar  4 22:24:13 2010
From: manlio.perillo at gmail.com (Manlio Perillo)
Date: Thu, 04 Mar 2010 22:24:13 +0100
Subject: [Distutils] easy_install is not robust against network errors
Message-ID: <4B9024FD.1070102@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have found that easy_install is not very robust against network problems.

$easy_install --version
distribute 0.6.10


Searching for SQLAlchemy==dev
Reading http://pypi.python.org/simple/SQLAlchemy/
Download error: (113, 'No route to host') -- Some packages may not be found!
Couldn't retrieve index page for 'SQLAlchemy'
Scanning index of all packages (this may take a while)
Reading http://pypi.python.org/simple/
Download error: (101, 'Network is unreachable') -- Some packages may not
be found!
No local packages or download links found for SQLAlchemy==dev
Best match: None
Traceback (most recent call last):
  File "organizzasposi/deps/bin/easy_install", line 8, in <module>
    load_entry_point('setuptools==0.6c11', 'console_scripts',
'easy_install')()
  File
"/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/command/easy_install.py",
line 1712, in main
  File
"/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/command/easy_install.py",
line 1700, in with_ei_usage
  File
"/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/command/easy_install.py",
line 1716, in <lambda>
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File
"/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/command/easy_install.py",
line 211, in run
  File
"/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/command/easy_install.py",
line 434, in easy_install
  File
"/home/manlio/.../deps/lib/python2.5/site-packages/setuptools-0.6c11-py2.5.egg/setuptools/package_index.py",
line 475, in fetch_distribution
AttributeError: 'NoneType' object has no attribute 'clone'



Thanks  Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuQJP0ACgkQscQJ24LbaUREHgCgmZSiaiEzN7EyMWCOrcEtVJqm
W/YAn0cGNpJXjTL3CflWHIzad5FikjLW
=wZeY
-----END PGP SIGNATURE-----

From pje at telecommunity.com  Sat Mar  6 19:05:36 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 06 Mar 2010 13:05:36 -0500
Subject: [Distutils] trouble building setuptools on centos 3.8
In-Reply-To: <78181ce61003021152s5f331f83i40cd2a249980f2d0@mail.gmail.co
 m>
References: <78181ce61003021152s5f331f83i40cd2a249980f2d0@mail.gmail.com>
Message-ID: <20100306180535.127CE3A4077@sparrow.telecommunity.com>

At 02:52 PM 3/2/2010 -0500, Mathieu Jobin wrote:
>maybe you can help me. there is something wrong with building this 
>rpm package ?
>
>maybe because I am running ....
>
>Python 2.2.3 (#1, May ? 1 2006, 12:33:49)

Setuptools requires Python 2.3, preferably 2.3.5 or higher.


From pje at telecommunity.com  Sat Mar  6 19:06:51 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 06 Mar 2010 13:06:51 -0500
Subject: [Distutils] Newby Question: install easy_install for python2.5
 on RHEL
In-Reply-To: <55AD1EEF173837488F4B56BEFC99B71C41D02D@server.aperiogroup. local>
References: <55AD1EEF173837488F4B56BEFC99B71C41D02D@server.aperiogroup.local>
Message-ID: <20100306180650.6EC713A4077@sparrow.telecommunity.com>

At 01:22 PM 3/2/2010 -0800, Walter Coole wrote:
>Content-Class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01CABA4E.86D76612"
>
>When I try to install with:
>
>                 sudo sh setuptools-0.6c11-py2.5.egg
>
>I get an error:
>
>                 error: invalid Python installation: unable to open 
> /usr/lib64/python2.5/config/Makefile (No such file or directory)
>
>That I don't really understand.  Yes, it's true that there is no 
>/usr/lib64/python2.5/config directory, but I've gotten along nicely 
>without one for quite a while.

You are probably missing your distribution's "python-dev" or 
"python-devel" package, which is required to use the distutils at 
all, let alone setuptools.


From setuptools at bugs.python.org  Mon Mar  8 13:38:38 2010
From: setuptools at bugs.python.org (Dan Cotruta)
Date: Mon, 08 Mar 2010 12:38:38 +0000
Subject: [Distutils] [issue104] bdist_egg ignoring egg_info:writers
In-Reply-To: <1268051918.63.0.630385066241.issue104@psf.upfronthosting.co.za>
Message-ID: <1268051918.63.0.630385066241.issue104@psf.upfronthosting.co.za>


New submission from Dan Cotruta <dan.cotruta at artsalliancemedia.com>:

It seems that creating eggs with bdist_egg does not read egg_info writers for extra files to be placed in EGG-INFO. Running setup.py egg_info first fixes the problem, but it seems like this step should not be necessary.
Am I mistaken, or is this a real bug?

----------
messages: 507
nosy: dcotruta
priority: bug
status: unread
title: bdist_egg ignoring egg_info:writers

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue104>
_______________________________________________

From setuptools at bugs.python.org  Tue Mar  9 07:49:49 2010
From: setuptools at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 09 Mar 2010 06:49:49 +0000
Subject: [Distutils] [issue105] include a copy of the licence text
In-Reply-To: <1268117388.92.0.665288299953.issue105@psf.upfronthosting.co.za>
Message-ID: <1268117388.92.0.665288299953.issue105@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

I am trying to get Tahoe-LAFS listed on the FSF/UNESCO directory of Free Software: http://directory.fsf.org/ . One of the sticking points is that Tahoe-LAFS includes a copy of setuptools (http://allmydata.org/trac/tahoe-lafs/browser/misc/dependencies/setuptools-0.6c12dev.egg?rev=20090205152818-92b7f-68bbee545bd9198bb3c4eb7cf9b84bf7d93e09d6 ) and, as the FSF representative wrote:

"""
Next, the following code misc/dependencies/setuptools/EGG-INFO/PKG-INFO
calls for either the Zope Public License or the Python Software
Foundation License neither of which is present. One of them needs to be
added in order to fix the problem.  Both can be found through links on
our website.
"""

To fix this, include a copy of the licence text with the distribution. (Or close this ticket as wontfix and I'll work-around it.)

----------
messages: 509
nosy: zooko
priority: wish
status: unread
title: include a copy of the licence text

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue105>
_______________________________________________

From harijay at gmail.com  Tue Mar  9 20:57:34 2010
From: harijay at gmail.com (hari jayaram)
Date: Tue, 9 Mar 2010 14:57:34 -0500
Subject: [Distutils] setuptools error when using --prefix option,
	complains directory does 	not exist
Message-ID: <aad3caa31003091157l12d2efa2rc494767c5abec01c@mail.gmail.com>

Hi

I am installing setuptools using the --prefix option it complains the
directory does not exist even though it does. The install works however when
I use the --instal-dir option as it recommends.

Thought I would pass this along
Hari




macbook-pro-17:~ hari$ sudo sh setuptools-0.6c11-py2.6.egg
--prefix=/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
error: can't create or remove files in install directory

The following error occurred while trying to add or remove files in the
installation directory:

    [Errno 2] No such file or directory:
'/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/lib/python2.6/site-packages/test-easy-install-79530.pth'

The installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:


 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/lib/python2.6/site-packages

This directory does not currently exist.  Please create it and try again, or
choose a different installation directory (using the -d or --install-dir
option).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100309/ce8c7ba2/attachment.html>

From janssen at parc.com  Tue Mar  9 21:28:16 2010
From: janssen at parc.com (Bill Janssen)
Date: Tue, 9 Mar 2010 12:28:16 PST
Subject: [Distutils] setuptools error when using --prefix option,
	complains directory does not exist
In-Reply-To: <aad3caa31003091157l12d2efa2rc494767c5abec01c@mail.gmail.com>
References: <aad3caa31003091157l12d2efa2rc494767c5abec01c@mail.gmail.com>
Message-ID: <8938.1268166496@parc.com>

Hari,

I think this works if you use "--root=/" along with "--prefix=foo".
So, if you wanted to install in, for example, "/Library/MyPackage/",
you'd say, "--root=/ --prefix=/Library/MyPackage".

I think this is better than using "--install-dir", because it handles
platform issues like "lib" vs "lib64" on Red Hat.

Bill

From bradallen137 at gmail.com  Tue Mar  9 22:03:47 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Tue, 9 Mar 2010 15:03:47 -0600
Subject: [Distutils] use of '_' in package name causing version parsing
	issue?
Message-ID: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>

Today I was informed of an issue in which buildout (with the latest
setuptools) is not resolving version numbers properly, causing the
wrong package to be selected in some cases. The cause identified was
having '_' in the package name. I am still investigating this issue,
but thought it would be worth mentioning on the list in case anyone
had a quick answer.

Here is the note I received which raised the issue:

| > The problem was, they used "_" in the package
| > name.  Buildout and many other systems like setuptools,RPM,DEB etc.
| > treat "_" as a special character to distinguish package name and
| > version.
| > So, it's not a good idea to use "_" in the name of a package.
| > The same is the situation with "-" (minus/hyphen) character.
| >
| > The lesson learned: Don't use "-" and "_" in package name.
|
| >>> import pkg_resources
| >>> a="jiva_interface-2.3.6-py2.6.egg"
| >>> b="jiva_interface-2.3.8-py2.6.egg"
| >>> pkg_resources.parse_version(a)
| ('*jiva', '*_', '*interface', '*final-', '00000002', '00000003',
| '00000006', '*final-', '*py', '00000002', '00000006', '*egg',
| '*final')
| >>> pkg_resources.parse_version(b)
| ('*jiva', '*_', '*interface', '*final-', '00000002', '00000003',
| '00000008', '*final-', '*py', '00000002', '00000006', '*egg',
| '*final')
| >>> c="ZeStorage-0.1.1-py2.4.egg"
| >>> d="ZeStorage-0.1.2-py2.4.egg"
| >>> pkg_resources.parse_version(c)
| ('*zestorage', '*final-', '00000000', '00000001', '00000001',
| '*final-', '*py', '00000002', '00000004', '*egg', '*final')
| >>> pkg_resources.parse_version(d)
| ('*zestorage', '*final-', '00000000', '00000001', '00000002',
| '*final-', '*py', '00000002', '00000004', '*egg', '*final')
|

From pje at telecommunity.com  Tue Mar  9 22:11:02 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 09 Mar 2010 16:11:02 -0500
Subject: [Distutils] setuptools error when using --prefix option,
 complains directory does 	not exist
In-Reply-To: <aad3caa31003091157l12d2efa2rc494767c5abec01c@mail.gmail.co
 m>
References: <aad3caa31003091157l12d2efa2rc494767c5abec01c@mail.gmail.com>
Message-ID: <20100309211057.726FA3A4108@sparrow.telecommunity.com>

At 02:57 PM 3/9/2010 -0500, hari jayaram wrote:
>Hi
>
>I am installing setuptools using the --prefix option it complains 
>the directory does not exist even though it does. The install works 
>however when I use the --instal-dir option as it recommends.
>
>macbook-pro-17:~ hari$ sudo sh setuptools-0.6c11-py2.6.egg 
>--prefix=/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages

That's because the directory you gave is not a *prefix*, it's an 
installation directory.
A prefix, in distutils terms, is generally the top-level directory 
under which Python's lib, bin, and other directories are located.

So, the correct --prefix would be 
"/Library/Frameworks/Python.framework/Versions/2.6" in this 
case.  (Notice the absence of lib/python2.6/site-packages.)


>     [Errno 2] No such file or directory: 
> '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/lib/python2.6/site-packages/test-easy-install-79530.pth'

If you look closely at this path, you'll see that when the distutils 
creates an install directory from your prefix (which is already an 
installation directory), you end up trying to install to a 
'lib/python2.6/site-packages/lib/python2.6/site-packages' 
directory.  That's because when you give a prefix, distutils decides 
what subdirectories of the prefix to install things in, and it can't 
tell that you already gave it a subdirectory of the prefix.


From pje at telecommunity.com  Tue Mar  9 23:24:18 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 09 Mar 2010 17:24:18 -0500
Subject: [Distutils] use of '_' in package name causing version parsing
 issue?
In-Reply-To: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.co
 m>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
Message-ID: <20100309222412.0ABB43A476B@sparrow.telecommunity.com>

At 03:03 PM 3/9/2010 -0600, Brad Allen wrote:
>Today I was informed of an issue in which buildout (with the latest
>setuptools) is not resolving version numbers properly, causing the
>wrong package to be selected in some cases. The cause identified was
>having '_' in the package name.

I suspect there is a miscommunication or misunderstanding 
somewhere.  It is perfectly acceptable to have a '_' in a package 
name or project name.  This:

>| >>> a="jiva_interface-2.3.6-py2.6.egg"
>| >>> b="jiva_interface-2.3.8-py2.6.egg"
>| >>> pkg_resources.parse_version(a)

Is the wrong API to use to parse an egg filename, as parse_version() 
is for parsing a version that's already extracted from a 
filename.  This is the right API for extracting a version from a filename:

 >>> pkg_resources.Distribution.from_filename(a).version
'2.3.6'
 >>> pkg_resources.Distribution.from_filename(b).version
'2.3.8'
 >>> pkg_resources.Distribution.from_filename(c).version
'0.1.1'
 >>> pkg_resources.Distribution.from_filename(d).version
'0.1.2'

And here's the correct one for extracting the parsed version from a filename:

 >>> pkg_resources.Distribution.from_filename(a).parsed_version
('00000002', '00000003', '00000006', '*final')
 >>> pkg_resources.Distribution.from_filename(b).parsed_version
('00000002', '00000003', '00000008', '*final')
 >>> pkg_resources.Distribution.from_filename(c).parsed_version
('00000000', '00000001', '00000001', '*final')
 >>> pkg_resources.Distribution.from_filename(d).parsed_version
('00000000', '00000001', '00000002', '*final')

As you can see, these APIs work just fine, so the example given is a 
red herring, unless Buildout is using the APIs incorrectly (which I 
really doubt it is).

Usually, the situation where people run into trouble with unusual 
package names or filenames is when they produce a source distribution 
manually, or by using something other than distutils/setuptools (that 
has different filename escaping rules), or when they manually rename 
a file before uploading, and expect it to still work the same.

It would be a good idea for you to check which of these things (if 
any) is taking place, and provide details of the specific problem, 
with steps to reproduce it, since the example given probably has 
nothing to do with it.  Thanks!


From bradallen137 at gmail.com  Tue Mar  9 23:46:56 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Tue, 9 Mar 2010 16:46:56 -0600
Subject: [Distutils] use of '_' in package name causing version parsing
	issue?
In-Reply-To: <20100309222412.0ABB43A476B@sparrow.telecommunity.com>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<20100309222412.0ABB43A476B@sparrow.telecommunity.com>
Message-ID: <4957f1ef1003091446v1016c1dckab87db8310504bfb@mail.gmail.com>

Thanks, that helps a lot.

From nad at acm.org  Wed Mar 10 00:07:56 2010
From: nad at acm.org (Ned Deily)
Date: Tue, 09 Mar 2010 15:07:56 -0800
Subject: [Distutils] setuptools error when using --prefix option,
	complains directory does 	not exist
References: <aad3caa31003091157l12d2efa2rc494767c5abec01c@mail.gmail.com>
	<aad3caa31003091157l12d2efa2rc494767c5abec01c@mail.gmail.co m>
	<20100309211057.726FA3A4108@sparrow.telecommunity.com>
Message-ID: <nad-D981F5.15075609032010@news.gmane.org>

In article <20100309211057.726FA3A4108 at sparrow.telecommunity.com>,
 "P.J. Eby" <pje at telecommunity.com> wrote:

> At 02:57 PM 3/9/2010 -0500, hari jayaram wrote:
> >I am installing setuptools using the --prefix option it complains 
> >the directory does not exist even though it does. The install works 
> >however when I use the --instal-dir option as it recommends.
> >
> >macbook-pro-17:~ hari$ sudo sh setuptools-0.6c11-py2.6.egg 
> >--prefix=/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site
> >-packages
> 
> That's because the directory you gave is not a *prefix*, it's an 
> installation directory.
> A prefix, in distutils terms, is generally the top-level directory 
> under which Python's lib, bin, and other directories are located.
> 
> So, the correct --prefix would be 
> "/Library/Frameworks/Python.framework/Versions/2.6" in this 
> case.  (Notice the absence of lib/python2.6/site-packages.)
> 
> 
> >     [Errno 2] No such file or directory: 
> > '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packag
> > es/lib/python2.6/site-packages/test-easy-install-79530.pth'
> 
> If you look closely at this path, you'll see that when the distutils 
> creates an install directory from your prefix (which is already an 
> installation directory), you end up trying to install to a 
> 'lib/python2.6/site-packages/lib/python2.6/site-packages' 
> directory.  That's because when you give a prefix, distutils decides 
> what subdirectories of the prefix to install things in, and it can't 
> tell that you already gave it a subdirectory of the prefix.

But adding extra parameters should be unnecessary in this case.  
/Library/Frameworks/Python.framework/Versions/2.6/lib is the default 
location for an OS X framework build, as when using the python.org 
installer.  To install setuptools, you just need to make sure you are 
using the python executable in that framework and distutils will take 
care of installing to the proper location:

 export PATH=/Library/Frameworks/Python.framework/Versions/2.6/bin:$PATH
 sh setuptools-0.6c11-py2.6.egg

-- 
 Ned Deily,
 nad at acm.org


From pje at telecommunity.com  Wed Mar 10 04:48:07 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 09 Mar 2010 22:48:07 -0500
Subject: [Distutils] setuptools error when using --prefix option,
 complains directory does 	not exist
In-Reply-To: <nad-D981F5.15075609032010@news.gmane.org>
References: <aad3caa31003091157l12d2efa2rc494767c5abec01c@mail.gmail.com>
	<aad3caa31003091157l12d2efa2rc494767c5abec01c@mail.gmail.co m>
	<20100309211057.726FA3A4108@sparrow.telecommunity.com>
	<nad-D981F5.15075609032010@news.gmane.org>
Message-ID: <20100310034803.9B4863A4062@sparrow.telecommunity.com>

At 03:07 PM 3/9/2010 -0800, Ned Deily wrote:
>But adding extra parameters should be unnecessary in this case.

True, but I was just explaining the difference between --prefix and 
--install-dir, which would be relevant for people on all platforms 
and most all installation directories.  ;-)


From mbaiju at zeomega.com  Wed Mar 10 18:50:32 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Wed, 10 Mar 2010 23:20:32 +0530
Subject: [Distutils] Fwd: use of '_' in package name causing version parsing
	issue?
In-Reply-To: <c911c70d1003092020w324999f2m7dcf9d5e7f403df0@mail.gmail.com>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<20100309222412.0ABB43A476B@sparrow.telecommunity.com>
	<c911c70d1003092020w324999f2m7dcf9d5e7f403df0@mail.gmail.com>
Message-ID: <c911c70d1003100950m1342e410qd191153a3b4f0bfa@mail.gmail.com>

Hi,

I was not subscribed to this list when I replied. So forwarding my own mail.


Regards,
Baiju M


---------- Forwarded message ----------
From: Baiju M <mbaiju at zeomega.com>
Date: Wed, Mar 10, 2010 at 9:50 AM
Subject: Re: [Distutils] use of '_' in package name causing version
parsing issue?
To: "P.J. Eby" <pje at telecommunity.com>
Cc: Brad Allen <bradallen137 at gmail.com>, distutils-sig at python.org,
dparmar at zeomega.com, Ponnusamy A <aponnusamy at zeomega.com>,
akader at zeomega.com, Jim Fulton <jim at zope.com>


On Wed, Mar 10, 2010 at 3:54 AM, P.J. Eby <pje at telecommunity.com> wrote:
> At 03:03 PM 3/9/2010 -0600, Brad Allen wrote:
>>
>> Today I was informed of an issue in which buildout (with the latest
>> setuptools) is not resolving version numbers properly, causing the
>> wrong package to be selected in some cases. The cause identified was
>> having '_' in the package name.
>
> I suspect there is a miscommunication or misunderstanding somewhere. ?It is
> perfectly acceptable to have a '_' in a package name or project name. ?This:
>
>> | >>> a="jiva_interface-2.3.6-py2.6.egg"
>> | >>> b="jiva_interface-2.3.8-py2.6.egg"
>> | >>> pkg_resources.parse_version(a)
>
> Is the wrong API to use to parse an egg filename, as parse_version() is for
> parsing a version that's already extracted from a filename. ?This is the
> right API for extracting a version from a filename:
>
>>>> pkg_resources.Distribution.from_filename(a).version
> '2.3.6'
>>>> pkg_resources.Distribution.from_filename(b).version
> '2.3.8'
>>>> pkg_resources.Distribution.from_filename(c).version
> '0.1.1'
>>>> pkg_resources.Distribution.from_filename(d).version
> '0.1.2'
>
> And here's the correct one for extracting the parsed version from a
> filename:
>
>>>> pkg_resources.Distribution.from_filename(a).parsed_version
> ('00000002', '00000003', '00000006', '*final')
>>>> pkg_resources.Distribution.from_filename(b).parsed_version
> ('00000002', '00000003', '00000008', '*final')
>>>> pkg_resources.Distribution.from_filename(c).parsed_version
> ('00000000', '00000001', '00000001', '*final')
>>>> pkg_resources.Distribution.from_filename(d).parsed_version
> ('00000000', '00000001', '00000002', '*final')
>
> As you can see, these APIs work just fine, so the example given is a red
> herring, unless Buildout is using the APIs incorrectly (which I really doubt
> it is).
>
> Usually, the situation where people run into trouble with unusual package
> names or filenames is when they produce a source distribution manually, or
> by using something other than distutils/setuptools (that has different
> filename escaping rules), or when they manually rename a file before
> uploading, and expect it to still work the same.
>
> It would be a good idea for you to check which of these things (if any) is
> taking place, and provide details of the specific problem, with steps to
> reproduce it, since the example given probably has nothing to do with it.

I spend some time with Buildout and setuptools code to identify the issue.
I will try to explain my findings.

1. Buildout is relying on pkg_resources.Requirement.parse function to
? ?get the "project_name" like this:

? ? pkg_resources.Requirement.parse('jiva_interface').project_name

? ?I can see from the code of `Requirement` class that, the `__init__`
? ?method is deprecated and recommend to use `parse`
? ?function. Does this mean that we should not use the attributes
? ?of an instance of `Requirement` class? ?This is very important as
? ?the `parse` function return a list of instances of `Requirement` class.

? So, if it is acceptable to use the "project_name" attribute, then
? Buildout can rely on it, right ?

? Here is beginning of `Requirement` class:

? ?class Requirement:
? ? ? ?def __init__(self, project_name, specs, extras):
? ? ? ? ? ?"""DO NOT CALL THIS UNDOCUMENTED METHOD; use Requirement.parse()!"""

2. This is the code which get the "project_name" in the same `__init__` method:

? ? ? ?self.unsafe_name, project_name = project_name, safe_name(project_name)
? ? ? ?self.project_name, self.key = project_name, project_name.lower()

? ?I looked at the "safe_name" method:

? ?def safe_name(name):
? ? ? ?"""Convert an arbitrary string to a standard distribution name

? ? ? ?Any runs of non-alphanumeric/. characters are replaced with a
single '-'.
? ? ? ?"""
? ? ? ?return re.sub('[^A-Za-z0-9.]+', '-', name)

? According to this code, this will be the result:

? ? pkg_resources.safe_name('jiva_interface')
? ? 'jiva-interface'

? And:

? ? pkg_resources.Requirement.parse('jiva_interface').project_name
? ? 'jiva-interface'

? ?Is this behavior correct ?

? ?If you think what setuptools doing is fine, we will make changes
? ?in Buildout code to use the "safe_name" method where ever it directly
? ?get "project_name".

Regards,
Baiju M

From bradallen137 at gmail.com  Wed Mar 10 21:18:49 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Wed, 10 Mar 2010 14:18:49 -0600
Subject: [Distutils] use of '_' in package name causing version parsing
	issue?
In-Reply-To: <20100309222412.0ABB43A476B@sparrow.telecommunity.com>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<20100309222412.0ABB43A476B@sparrow.telecommunity.com>
Message-ID: <4957f1ef1003101218q647fb01bn8756f3e80dccda0d@mail.gmail.com>

On Tue, Mar 9, 2010 at 4:24 PM, P.J. Eby <pje at telecommunity.com> wrote:
> As you can see, these APIs work just fine, so the example given is a red
> herring, unless Buildout is using the APIs incorrectly (which I really doubt
> it is).

Based on Baiju's input above describing buildout's use of
Requirements.parse, do think a change needs to be made in buildout?

From pje at telecommunity.com  Thu Mar 11 05:39:08 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 10 Mar 2010 23:39:08 -0500
Subject: [Distutils] use of '_' in package name causing version parsing
 issue?
In-Reply-To: <c911c70d1003092020w324999f2m7dcf9d5e7f403df0@mail.gmail.co
 m>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<20100309222412.0ABB43A476B@sparrow.telecommunity.com>
	<c911c70d1003092020w324999f2m7dcf9d5e7f403df0@mail.gmail.com>
Message-ID: <20100311043920.6B0433A4062@sparrow.telecommunity.com>

At 09:50 AM 3/10/2010 +0530, Baiju M wrote:
>I spend some time with Buildout and setuptools code to identify the issue.
>I will try to explain my findings.
>
>1. Buildout is relying on pkg_resources.Requirement.parse function to
>     get the "project_name" like this:
>
>      pkg_resources.Requirement.parse('jiva_interface').project_name
>
>     I can see from the code of `Requirement` class that, the `__init__`
>     method is deprecated and recommend to use `parse`
>     function.

It is undocumented, not deprecated.  You are simply not supposed to 
create instances via that (private) constructor.


>  Does this mean that we should not use the attributes
>     of an instance of `Requirement` class?  This is very important as
>     the `parse` function return a list of instances of `Requirement` class.

Requirement objects are documented; see:

   http://peak.telecommunity.com/DevCenter/PkgResources#requirement-objects



>    So, if it is acceptable to use the "project_name" attribute, then
>    Buildout can rely on it, right ?

Yes.


>    According to this code, this will be the result:
>
>      pkg_resources.safe_name('jiva_interface')
>      'jiva-interface'
>
>    And:
>
>      pkg_resources.Requirement.parse('jiva_interface').project_name
>      'jiva-interface'
>
>     Is this behavior correct ?

Yes it is. All non-alphanumeric, non-dot characters are replaced with 
'-' in a project name.  This turns project names like e.g. "Foo's Bar 
Factory" into their canonical form (i.e., "Foo-s-Bar-Factory").


>     If you think what setuptools doing is fine, we will make changes
>     in Buildout code to use the "safe_name" method where ever it directly
>     get "project_name".

Why do you think you need that?  (Most likely, you are mistaken, 
since the only reason the unsafe_name attribute exists is to deal 
with a limitation in older versions of the PyPI software, which did 
not support doing "safe_name" redirection.)

If you can describe what you're actually trying to do with this 
information, perhaps there is a safer/more documented way that I can suggest.


From mbaiju at zeomega.com  Thu Mar 11 06:35:00 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Thu, 11 Mar 2010 11:05:00 +0530
Subject: [Distutils] use of '_' in package name causing version parsing
	issue?
In-Reply-To: <20100311043920.6B0433A4062@sparrow.telecommunity.com>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<20100309222412.0ABB43A476B@sparrow.telecommunity.com>
	<c911c70d1003092020w324999f2m7dcf9d5e7f403df0@mail.gmail.com>
	<20100311043920.6B0433A4062@sparrow.telecommunity.com>
Message-ID: <c911c70d1003102135y2dd53c5eia0514cb9dac7b575@mail.gmail.com>

On Thu, Mar 11, 2010 at 10:09 AM, P.J. Eby <pje at telecommunity.com> wrote:
> At 09:50 AM 3/10/2010 +0530, Baiju M wrote:
>>
>> I spend some time with Buildout and setuptools code to identify the issue.
>> I will try to explain my findings.
>>
>> 1. Buildout is relying on pkg_resources.Requirement.parse function to
>> ? ?get the "project_name" like this:
>>
>> ? ? pkg_resources.Requirement.parse('jiva_interface').project_name
>>
>> ? ?I can see from the code of `Requirement` class that, the `__init__`
>> ? ?method is deprecated and recommend to use `parse`
>> ? ?function.
>
> It is undocumented, not deprecated. ?You are simply not supposed to create
> instances via that (private) constructor.

Okay, fine.  Buildout doesn't create any instance directly.

>> ?Does this mean that we should not use the attributes
>> ? ?of an instance of `Requirement` class? ?This is very important as
>> ? ?the `parse` function return a list of instances of `Requirement` class.
>
> Requirement objects are documented; see:
>
> ?http://peak.telecommunity.com/DevCenter/PkgResources#requirement-objects

So, according to the EBNF given there, "_" is a valid project_name identifier:

  project_name ::= identifier
  identifier   ::= [-A-Za-z0-9_]+

>> ? So, if it is acceptable to use the "project_name" attribute, then
>> ? Buildout can rely on it, right ?
>
> Yes.
>
>> ? According to this code, this will be the result:
>>
>> ? ? pkg_resources.safe_name('jiva_interface')
>> ? ? 'jiva-interface'
>>
>> ? And:
>>
>> ? ? pkg_resources.Requirement.parse('jiva_interface').project_name
>> ? ? 'jiva-interface'
>>
>> ? ?Is this behavior correct ?
>
> Yes it is. All non-alphanumeric, non-dot characters are replaced with '-' in
> a project name. ?This turns project names like e.g. "Foo's Bar Factory" into
> their canonical form (i.e., "Foo-s-Bar-Factory").

If "_" is a valid project_name identifier, why it is replaces with "-" ?

>> ? ?If you think what setuptools doing is fine, we will make changes
>> ? ?in Buildout code to use the "safe_name" method where ever it directly
>> ? ?get "project_name".
>
> Why do you think you need that? ?(Most likely, you are mistaken, since the
> only reason the unsafe_name attribute exists is to deal with a limitation in
> older versions of the PyPI software, which did not support doing "safe_name"
> redirection.)
>
> If you can describe what you're actually trying to do with this information,
> perhaps there is a safer/more documented way that I can suggest.

Buildout has a functionality to "pin-down" ("lock down"/"nail down") versions
of eggs (distribution?).  There is another functionality to enforce
"pinining-down"
versions of all eggs used in a particular Buildout configuration.  If we
use "_" as the package name (distribution name?), this functionality is not
working.

I need some time to explain this further with a proper test case in Buildout.

Regards,
Baiju M

From mbaiju at zeomega.com  Thu Mar 11 08:08:49 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Thu, 11 Mar 2010 12:38:49 +0530
Subject: [Distutils] use of '_' in package name causing version parsing
	issue?
In-Reply-To: <c911c70d1003102135y2dd53c5eia0514cb9dac7b575@mail.gmail.com>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<20100309222412.0ABB43A476B@sparrow.telecommunity.com>
	<c911c70d1003092020w324999f2m7dcf9d5e7f403df0@mail.gmail.com>
	<20100311043920.6B0433A4062@sparrow.telecommunity.com>
	<c911c70d1003102135y2dd53c5eia0514cb9dac7b575@mail.gmail.com>
Message-ID: <c911c70d1003102308h62908555gf8408f40429f99c9@mail.gmail.com>

On Thu, Mar 11, 2010 at 11:05 AM, Baiju M <mbaiju at zeomega.com> wrote:
> On Thu, Mar 11, 2010 at 10:09 AM, P.J. Eby <pje at telecommunity.com> wrote:
>> At 09:50 AM 3/10/2010 +0530, Baiju M wrote:
>>>
>>> I spend some time with Buildout and setuptools code to identify the issue.
>>> I will try to explain my findings.
>>>
>>> 1. Buildout is relying on pkg_resources.Requirement.parse function to
>>> ? ?get the "project_name" like this:
>>>
>>> ? ? pkg_resources.Requirement.parse('jiva_interface').project_name
>>>
>>> ? ?I can see from the code of `Requirement` class that, the `__init__`
>>> ? ?method is deprecated and recommend to use `parse`
>>> ? ?function.
>>
>> It is undocumented, not deprecated. ?You are simply not supposed to create
>> instances via that (private) constructor.
>
> Okay, fine. ?Buildout doesn't create any instance directly.
>
>>> ?Does this mean that we should not use the attributes
>>> ? ?of an instance of `Requirement` class? ?This is very important as
>>> ? ?the `parse` function return a list of instances of `Requirement` class.
>>
>> Requirement objects are documented; see:
>>
>> ?http://peak.telecommunity.com/DevCenter/PkgResources#requirement-objects
>
> So, according to the EBNF given there, "_" is a valid project_name identifier:
>
> ?project_name ::= identifier
> ?identifier ? ::= [-A-Za-z0-9_]+
>
>>> ? So, if it is acceptable to use the "project_name" attribute, then
>>> ? Buildout can rely on it, right ?
>>
>> Yes.
>>
>>> ? According to this code, this will be the result:
>>>
>>> ? ? pkg_resources.safe_name('jiva_interface')
>>> ? ? 'jiva-interface'
>>>
>>> ? And:
>>>
>>> ? ? pkg_resources.Requirement.parse('jiva_interface').project_name
>>> ? ? 'jiva-interface'
>>>
>>> ? ?Is this behavior correct ?
>>
>> Yes it is. All non-alphanumeric, non-dot characters are replaced with '-' in
>> a project name. ?This turns project names like e.g. "Foo's Bar Factory" into
>> their canonical form (i.e., "Foo-s-Bar-Factory").
>
> If "_" is a valid project_name identifier, why it is replaces with "-" ?

There nearly 300 packages in PyPI with "_" in the package name.
For all the packages built using Setuptools, the "Name" field in
the PKG-INFO file is replaced with "-".

I checked some of the packages built with "distutils.core" [1]
Distutils is not replacing "Name" field in PKG-INFO file
with "-".

Why Setuptools is behaving different from Distutils ?

Regards,
Baiju M

[1] http://pypi.python.org/pypi/text_table/0.02

From chris at simplistix.co.uk  Thu Mar 11 14:34:23 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 11 Mar 2010 13:34:23 +0000
Subject: [Distutils] RFC: Barely minimal CI + tests + packaging in
 Python WAS: Guidelines for where to put tests & how to package them
In-Reply-To: <20100301195412.BC1053A40A7@sparrow.telecommunity.com>
References: <24ea26601002250741n1c42b271oc96b7466853bd970@mail.gmail.com>	<20100225170007.3A66D3A406A@sparrow.telecommunity.com>	<4B8C13EA.3010100@simplistix.co.uk>
	<20100301195412.BC1053A40A7@sparrow.telecommunity.com>
Message-ID: <4B98F15F.7000807@simplistix.co.uk>

P.J. Eby wrote:
> At 07:22 PM 3/1/2010 +0000, Chris Withers wrote:
>> P.J. Eby wrote:
>>> At 10:41 AM 2/25/2010 -0500, Olemis Lang wrote:
>>>> PS: BTW, how could I trigger easy_install(ation) at a given point
>>>> while implementing a distutils command, and let the command perform
>>>> further actions if deps are installed correctly ?
>>> Setuptools' "Distribution" object has a method for fetching 
>>> dependencies.  See setuptools' "test" command for an example.  (This 
>>> doesn't install the dependencies globally, just drops eggs into the 
>>> build directory.  But they're there and available to be reused for 
>>> installation in a later phase, under normal circumstances.)
>>
>> ...which is all pretty grim. If you use this with other packaging 
>> tools, like, say, buildout, the testing dependencies just get dumped 
>> into your buildout, which is a bit yucky to put it mildly.
>>
>> How about putting them where other eggs get put but only making them 
>> available for the tests?
>>
>> Failing that, how about putting them somewhere temporary?
> 
> They *are* somewhere temporary.  Buildout's not going to install them 
> from the setup.py directory, and neither will anything else.

When I last tried using setuptools test_require stuff (in a buildout 
driven pylons app, iirc) I ended up with the resulting eggs dumped in 
the root of my buildout and no, the ddn't go away at the end of the test 
run...

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From olemis at gmail.com  Thu Mar 11 14:46:32 2010
From: olemis at gmail.com (Olemis Lang)
Date: Thu, 11 Mar 2010 08:46:32 -0500
Subject: [Distutils] RFC: Barely minimal CI + tests + packaging in
	Python WAS: Guidelines for where to put tests & how to package them
In-Reply-To: <4B98F15F.7000807@simplistix.co.uk>
References: <24ea26601002250741n1c42b271oc96b7466853bd970@mail.gmail.com>
	<20100225170007.3A66D3A406A@sparrow.telecommunity.com>
	<4B8C13EA.3010100@simplistix.co.uk>
	<20100301195412.BC1053A40A7@sparrow.telecommunity.com>
	<4B98F15F.7000807@simplistix.co.uk>
Message-ID: <24ea26601003110546y2fba044ch5fedcbd8b374134e@mail.gmail.com>

On Thu, Mar 11, 2010 at 8:34 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> P.J. Eby wrote:
>>
>> At 07:22 PM 3/1/2010 +0000, Chris Withers wrote:
>>>
>>> P.J. Eby wrote:
>>>>
>>>> At 10:41 AM 2/25/2010 -0500, Olemis Lang wrote:
>>>>>
>>>>> PS: BTW, how could I trigger easy_install(ation) at a given point
>>>>> while implementing a distutils command, and let the command perform
>>>>> further actions if deps are installed correctly ?
>>>>
>>>> Setuptools' "Distribution" object has a method for fetching
>>>> dependencies. ?See setuptools' "test" command for an example. ?(This doesn't
>>>> install the dependencies globally, just drops eggs into the build directory.
>>>> ?But they're there and available to be reused for installation in a later
>>>> phase, under normal circumstances.)
>>>
>>> ...which is all pretty grim. If you use this with other packaging tools,
>>> like, say, buildout, the testing dependencies just get dumped into your
>>> buildout, which is a bit yucky to put it mildly.
>>>
>>> How about putting them where other eggs get put but only making them
>>> available for the tests?
>>>
>>> Failing that, how about putting them somewhere temporary?
>>
>> They *are* somewhere temporary. ?Buildout's not going to install them from
>> the setup.py directory, and neither will anything else.
>
> When I last tried using setuptools test_require stuff (in a buildout driven
> pylons app, iirc) I ended up with the resulting eggs dumped in the root of
> my buildout and no, the ddn't go away at the end of the test run...
>

I don't use buildout so I think my ideas are not of much help in this
case, but I use just virtualenv for CI and in this case AFAICR
everything remained inside the temp buildenv created for this purpose
(anyway I'll try it once again ASAIC to confirm ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

From gustavonarea at 2degreesnetwork.com  Thu Mar 11 16:32:43 2010
From: gustavonarea at 2degreesnetwork.com (Gustavo Narea)
Date: Thu, 11 Mar 2010 15:32:43 +0000
Subject: [Distutils] Buildout: Version conflicts with system-wide libraries
Message-ID: <4B990D1B.5090807@2degreesnetwork.com>

Hello,

On my Ubuntu desktop, httplib2 v0.4.0 is installed system-wide because
it's required by many things. However, I need to use v0.6.0 of that
package in my Buildout-powered project.

But when I run Buildout, I get this error:
=====
VersionConflict: (httplib2 0.4.0 (/usr/lib/pymodules/python2.5),
Requirement.parse('httplib2==0.6.0'))
=====

I've hit this problem before and what I had done is to remove the
system-wide install, which I cannot do this time.

There has to be a way for Buildout to ignore the global install, but I
could not find the answer after reading the documentation.

Can you please help me?

Cheers,

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degreesnetwork.com/>.


From pje at telecommunity.com  Thu Mar 11 16:43:02 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 11 Mar 2010 10:43:02 -0500
Subject: [Distutils] use of '_' in package name causing version parsing
 issue?
In-Reply-To: <c911c70d1003102308h62908555gf8408f40429f99c9@mail.gmail.co
 m>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<20100309222412.0ABB43A476B@sparrow.telecommunity.com>
	<c911c70d1003092020w324999f2m7dcf9d5e7f403df0@mail.gmail.com>
	<20100311043920.6B0433A4062@sparrow.telecommunity.com>
	<c911c70d1003102135y2dd53c5eia0514cb9dac7b575@mail.gmail.com>
	<c911c70d1003102308h62908555gf8408f40429f99c9@mail.gmail.com>
Message-ID: <20100311154303.A45613A40AF@sparrow.telecommunity.com>

At 12:38 PM 3/11/2010 +0530, Baiju M wrote:
>On Thu, Mar 11, 2010 at 11:05 AM, Baiju M <mbaiju at zeomega.com> wrote:
> > If "_" is a valid project_name identifier, why it is replaces with "-" ?

In order to have a canonicalized name form which can be escaped in 
filenames for unambiguous identification of an egg's project and version.

Egg filenames use '-' as a separator between name, version, python 
version, and platform.  A '-' in any of these components is escaped 
as '_', so that the '-' remains a viable and unambiguous 
separator.  This means that '_' gets turned back into a '-' when 
unescaped, so the mapping between '_' and '-' is part of the 
safe_name canonical form.


>There nearly 300 packages in PyPI with "_" in the package name.
>For all the packages built using Setuptools, the "Name" field in
>the PKG-INFO file is replaced with "-".
>
>I checked some of the packages built with "distutils.core" [1]
>Distutils is not replacing "Name" field in PKG-INFO file
>with "-".
>
>Why Setuptools is behaving different from Distutils ?

Because distutils wasn't built in a world where: package names needed 
to be uniquely and unambiguously machine-parseable from 
filenames.  The code that easy_install has for dealing with 
distutils-named source distributions has to guess at possible 
interpretations of those filenames, because distutils filenames don't 
distinguish between a '-' in a name or version, and a '-' *between* 
names and versions.

Ultimately, the simplest way to deal with this was to treat runs of 
'_' (or any other non-alphanum, non-dot character), as being 
identical to a single '-'.


>Buildout has a functionality to "pin-down" ("lock down"/"nail down") versions
>of eggs (distribution?).  There is another functionality to enforce
>"pinining-down"
>versions of all eggs used in a particular Buildout configuration.  If we
>use "_" as the package name (distribution name?), this functionality is not
>working.

Your comparisons should be based on the 'key' attribute of 
Distribution and Requirement objects, rather than relying on direct 
string operations of your own.  The 'key' attribute contains a form 
of project name suitable for equality/inequality comparisons.

In other words, you should not take unparsed data from your 
configuration and compare it against pkg_resources attributes.  Use 
constructors like using Requirement.parse() and 
Distribution.from_filename() to create objects with 'key' attributes, 
then compare keys, or just use Requirement.__contains__.  For example:

     if someDistribution in Requirement.parse(projname+'=='+exactversion):
          # someDistribution is exactly version exactversion of projname

The pkg_resources API is there precisely so that you don't have to 
know all the low-level details like syntax rules and escaping.




From pje at telecommunity.com  Thu Mar 11 16:45:55 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 11 Mar 2010 10:45:55 -0500
Subject: [Distutils] RFC: Barely minimal CI + tests + packaging in
 Python WAS: Guidelines for where to put tests & how to package them
In-Reply-To: <4B98F15F.7000807@simplistix.co.uk>
References: <24ea26601002250741n1c42b271oc96b7466853bd970@mail.gmail.com>
	<20100225170007.3A66D3A406A@sparrow.telecommunity.com>
	<4B8C13EA.3010100@simplistix.co.uk>
	<20100301195412.BC1053A40A7@sparrow.telecommunity.com>
	<4B98F15F.7000807@simplistix.co.uk>
Message-ID: <20100311154553.20F163A40AF@sparrow.telecommunity.com>

At 01:34 PM 3/11/2010 +0000, Chris Withers wrote:
>When I last tried using setuptools test_require stuff (in a buildout 
>driven pylons app, iirc) I ended up with the resulting eggs dumped 
>in the root of my buildout and no, the ddn't go away at the end of 
>the test run...

Interesting.  Must be an artifact of how buildout calls things, then, 
because setuptools drops them to the *current* directory, under 
circumstances that assume it's running in the setup.py directory.  If 
buildout is calling it *programmatically*, then all bets are off; 
it's effectively buildout's responsibility to set the current 
directory appropriately before invoking the test command (or any 
other setup command, for that matter).


From chris at simplistix.co.uk  Thu Mar 11 16:47:32 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 11 Mar 2010 15:47:32 +0000
Subject: [Distutils] RFC: Barely minimal CI + tests + packaging in
 Python WAS: Guidelines for where to put tests & how to package them
In-Reply-To: <20100311154553.20F163A40AF@sparrow.telecommunity.com>
References: <24ea26601002250741n1c42b271oc96b7466853bd970@mail.gmail.com>
	<20100225170007.3A66D3A406A@sparrow.telecommunity.com>
	<4B8C13EA.3010100@simplistix.co.uk>
	<20100301195412.BC1053A40A7@sparrow.telecommunity.com>
	<4B98F15F.7000807@simplistix.co.uk>
	<20100311154553.20F163A40AF@sparrow.telecommunity.com>
Message-ID: <4B991094.9030605@simplistix.co.uk>

P.J. Eby wrote:
> At 01:34 PM 3/11/2010 +0000, Chris Withers wrote:
>> When I last tried using setuptools test_require stuff (in a buildout 
>> driven pylons app, iirc) I ended up with the resulting eggs dumped in 
>> the root of my buildout and no, the ddn't go away at the end of the 
>> test run...
> 
> Interesting.  Must be an artifact of how buildout calls things, then, 
> because setuptools drops them to the *current* directory, under 
> circumstances that assume it's running in the setup.py directory. 

It is, but for a develop egg, that's your checkout, and that's where the 
testing dependency eggs get dumped!

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From jim at zope.com  Thu Mar 11 17:00:19 2010
From: jim at zope.com (Jim Fulton)
Date: Thu, 11 Mar 2010 11:00:19 -0500
Subject: [Distutils] Buildout: Version conflicts with system-wide
	libraries
In-Reply-To: <4B990D1B.5090807@2degreesnetwork.com>
References: <4B990D1B.5090807@2degreesnetwork.com>
Message-ID: <1099b90b1003110800me2d26ecxbf9e914d5c71a1f@mail.gmail.com>

On Thu, Mar 11, 2010 at 10:32 AM, Gustavo Narea
<gustavonarea at 2degreesnetwork.com> wrote:
> Hello,
>
> On my Ubuntu desktop, httplib2 v0.4.0 is installed system-wide because
> it's required by many things. However, I need to use v0.6.0 of that
> package in my Buildout-powered project.
>
> But when I run Buildout, I get this error:
> =====
> VersionConflict: (httplib2 0.4.0 (/usr/lib/pymodules/python2.5),
> Requirement.parse('httplib2==0.6.0'))
> =====
>
> I've hit this problem before and what I had done is to remove the
> system-wide install, which I cannot do this time.
>
> There has to be a way for Buildout to ignore the global install, but I
> could not find the answer after reading the documentation.
>
> Can you please help me?

There isn't currently an option to get buildout to ignore
site-packages, although an option to do that is under review.

Many of us simply avoid using system Python installs.  I personally
always have clean Python installs, independent from system Python,
that I use for applications.

Jim

-- 
Jim Fulton

From optilude+lists at gmail.com  Thu Mar 11 17:14:52 2010
From: optilude+lists at gmail.com (Martin Aspeli)
Date: Fri, 12 Mar 2010 00:14:52 +0800
Subject: [Distutils] Buildout: Version conflicts with system-wide
	libraries
In-Reply-To: <1099b90b1003110800me2d26ecxbf9e914d5c71a1f@mail.gmail.com>
References: <4B990D1B.5090807@2degreesnetwork.com>
	<1099b90b1003110800me2d26ecxbf9e914d5c71a1f@mail.gmail.com>
Message-ID: <hnb4ts$3s9$1@dough.gmane.org>

Jim Fulton wrote:
> On Thu, Mar 11, 2010 at 10:32 AM, Gustavo Narea
> <gustavonarea at 2degreesnetwork.com>  wrote:
>> Hello,
>>
>> On my Ubuntu desktop, httplib2 v0.4.0 is installed system-wide because
>> it's required by many things. However, I need to use v0.6.0 of that
>> package in my Buildout-powered project.
>>
>> But when I run Buildout, I get this error:
>> =====
>> VersionConflict: (httplib2 0.4.0 (/usr/lib/pymodules/python2.5),
>> Requirement.parse('httplib2==0.6.0'))
>> =====
>>
>> I've hit this problem before and what I had done is to remove the
>> system-wide install, which I cannot do this time.
>>
>> There has to be a way for Buildout to ignore the global install, but I
>> could not find the answer after reading the documentation.
>>
>> Can you please help me?
>
> There isn't currently an option to get buildout to ignore
> site-packages, although an option to do that is under review.
>
> Many of us simply avoid using system Python installs.  I personally
> always have clean Python installs, independent from system Python,
> that I use for applications.

I hope you merge that option ASAP. :)

The problem is not "us" who have pristine global Python's. It's "them" 
that we give our buildouts to and expect them to work the same as they 
did on our own machine: end users (Plone's installers are buildouts now, 
for example), sysadmins, and new developers.

Martin


From olemis at gmail.com  Thu Mar 11 17:15:21 2010
From: olemis at gmail.com (Olemis Lang)
Date: Thu, 11 Mar 2010 11:15:21 -0500
Subject: [Distutils] RFC: Barely minimal CI + tests + packaging in
	Python WAS: Guidelines for where to put tests & how to package them
In-Reply-To: <4B991094.9030605@simplistix.co.uk>
References: <24ea26601002250741n1c42b271oc96b7466853bd970@mail.gmail.com>
	<20100225170007.3A66D3A406A@sparrow.telecommunity.com>
	<4B8C13EA.3010100@simplistix.co.uk>
	<20100301195412.BC1053A40A7@sparrow.telecommunity.com>
	<4B98F15F.7000807@simplistix.co.uk>
	<20100311154553.20F163A40AF@sparrow.telecommunity.com>
	<4B991094.9030605@simplistix.co.uk>
Message-ID: <24ea26601003110815s5e6f71fax87d5fe5198df95b7@mail.gmail.com>

On Thu, Mar 11, 2010 at 10:47 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> P.J. Eby wrote:
>>
>> At 01:34 PM 3/11/2010 +0000, Chris Withers wrote:
>>>
>>> When I last tried using setuptools test_require stuff (in a buildout
>>> driven pylons app, iirc) I ended up with the resulting eggs dumped in the
>>> root of my buildout and no, the ddn't go away at the end of the test run...
>>
>> Interesting. ?Must be an artifact of how buildout calls things, then,
>> because setuptools drops them to the *current* directory, under
>> circumstances that assume it's running in the setup.py directory.
>
> It is, but for a develop egg, that's your checkout, and that's where the
> testing dependency eggs get dumped!
>

In order to do this in developer mode what I do is

{{{
#!sh

virtualenv buildenv
buildenv/bin/easy_install setuptools==dev
buildenv/bin/easy_install unittest-xml-reporting
buildenv/bin/easy_install ciutils
buildenv/bin/easy_install -eb . -f http://pypi.python.org/pypi/Trac/0.11.4 Trac
cd trac && ../buildenv/bin/python setup.py develop
cd trunk && ../buildenv/bin/python setup.py test -r ciutils:junitrunner

}}}

-b switch is for the download folder ;o)

PS: Real & full snippet is available to setup TracXmlRpc @ testrun.org
[1]_ . In fact this has ramifications related to Titus' thread about
packaging and illustrates how to install test code for a package that
normally doesn't include them (bdist_xxx), using `setuptools`

Wow ! I am learning about the setuptools thingie . I love it more and
more everyday !!! (probably until I find the hidden monsters ? where
are they ? :P )

.. [1] Hudson ? tracrpc ? tracrpc-th
         (http://hudson.testrun.org/view/tracrpc/job/tracrpc-th/configure)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
On adding Hessian (RPC) support for Trac -
http://feedproxy.google.com/~r/simelo-en/~3/Vit6dRudChU/on-adding-hessian-rpc-support-for-trac.html

From olemis at gmail.com  Thu Mar 11 17:22:17 2010
From: olemis at gmail.com (Olemis Lang)
Date: Thu, 11 Mar 2010 11:22:17 -0500
Subject: [Distutils] RFC: Barely minimal CI + tests + packaging in
	Python WAS: Guidelines for where to put tests & how to package them
In-Reply-To: <24ea26601003110815s5e6f71fax87d5fe5198df95b7@mail.gmail.com>
References: <24ea26601002250741n1c42b271oc96b7466853bd970@mail.gmail.com>
	<20100225170007.3A66D3A406A@sparrow.telecommunity.com>
	<4B8C13EA.3010100@simplistix.co.uk>
	<20100301195412.BC1053A40A7@sparrow.telecommunity.com>
	<4B98F15F.7000807@simplistix.co.uk>
	<20100311154553.20F163A40AF@sparrow.telecommunity.com>
	<4B991094.9030605@simplistix.co.uk>
	<24ea26601003110815s5e6f71fax87d5fe5198df95b7@mail.gmail.com>
Message-ID: <24ea26601003110822u7ad61212jfe50ba8c64cc94fc@mail.gmail.com>

On Thu, Mar 11, 2010 at 11:15 AM, Olemis Lang <olemis at gmail.com> wrote:
> On Thu, Mar 11, 2010 at 10:47 AM, Chris Withers <chris at simplistix.co.uk> wrote:
>> P.J. Eby wrote:
>>>
>>> At 01:34 PM 3/11/2010 +0000, Chris Withers wrote:
>>>>
>>>> When I last tried using setuptools test_require stuff (in a buildout
>>>> driven pylons app, iirc) I ended up with the resulting eggs dumped in the
>>>> root of my buildout and no, the ddn't go away at the end of the test run...
>>>
>>> Interesting. ?Must be an artifact of how buildout calls things, then,
>>> because setuptools drops them to the *current* directory, under
>>> circumstances that assume it's running in the setup.py directory.
>>
>> It is, but for a develop egg, that's your checkout, and that's where the
>> testing dependency eggs get dumped!
>>
>
> In order to do this in developer mode what I do is
>

Update (if you take a look at the real build job config, you'll notice why ;o)

> {{{
> #!sh
>
> virtualenv buildenv
> buildenv/bin/easy_install setuptools==dev
> buildenv/bin/easy_install unittest-xml-reporting
> buildenv/bin/easy_install ciutils
> buildenv/bin/easy_install -eb . -f http://pypi.python.org/pypi/Trac/0.11.4 Trac
> cd trac && ../buildenv/bin/python setup.py develop

cd ..

> cd trunk && ../buildenv/bin/python setup.py test -r ciutils:junitrunner
>

cd ..

> }}}
>

;o)

Featured article:
On adding Hessian (RPC) support for Trac -
http://feedproxy.google.com/~r/simelo-en/~3/Vit6dRudChU/on-adding-hessian-rpc-support-for-trac.html

From gustavonarea at 2degreesnetwork.com  Thu Mar 11 17:24:46 2010
From: gustavonarea at 2degreesnetwork.com (Gustavo Narea)
Date: Thu, 11 Mar 2010 16:24:46 +0000
Subject: [Distutils] Buildout: Version conflicts with system-wide
	libraries
In-Reply-To: <1268324465.13354.3.camel@alisah>
References: <4B990D1B.5090807@2degreesnetwork.com>
	<1268324465.13354.3.camel@alisah>
Message-ID: <4B99194E.5010205@2degreesnetwork.com>

Thanks, Yonsy. However I already do that :/

On 11/03/10 16:21, Yonsy Solis wrote:
> use virtualenv with --no-site-packages option, and run your buildout
> with the python from your virtualenv
>
> http://pypi.python.org/pypi/virtualenv
>
>   

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degreesnetwork.com/>.


From gustavonarea at 2degreesnetwork.com  Thu Mar 11 17:28:47 2010
From: gustavonarea at 2degreesnetwork.com (Gustavo Narea)
Date: Thu, 11 Mar 2010 16:28:47 +0000
Subject: [Distutils] Buildout: Version conflicts with system-wide
	libraries
In-Reply-To: <1099b90b1003110800me2d26ecxbf9e914d5c71a1f@mail.gmail.com>
References: <4B990D1B.5090807@2degreesnetwork.com>
	<1099b90b1003110800me2d26ecxbf9e914d5c71a1f@mail.gmail.com>
Message-ID: <4B991A3F.8000701@2degreesnetwork.com>

Thank you, Jim.

I think I'll have to have a separate Python.

Thank you!

On 11/03/10 16:00, Jim Fulton wrote:
> There isn't currently an option to get buildout to ignore
> site-packages, although an option to do that is under review.
>
> Many of us simply avoid using system Python installs.  I personally
> always have clean Python installs, independent from system Python,
> that I use for applications.
>   

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degreesnetwork.com/>.


From attilaolah at gmail.com  Thu Mar 11 17:44:50 2010
From: attilaolah at gmail.com (=?UTF-8?B?QXR0aWxhIE9sw6Fo?=)
Date: Thu, 11 Mar 2010 17:44:50 +0100
Subject: [Distutils] Buildout: Version conflicts with system-wide
	libraries
In-Reply-To: <hnb4ts$3s9$1@dough.gmane.org>
References: <4B990D1B.5090807@2degreesnetwork.com>
	<1099b90b1003110800me2d26ecxbf9e914d5c71a1f@mail.gmail.com> 
	<hnb4ts$3s9$1@dough.gmane.org>
Message-ID: <1da06521003110844y30ab997fmc072e78c95fe70cd@mail.gmail.com>

Hi,

On Thu, Mar 11, 2010 at 17:14, Martin Aspeli <optilude+lists at gmail.com> wrote:
> Jim Fulton wrote:
>>
>> On Thu, Mar 11, 2010 at 10:32 AM, Gustavo Narea
>> <gustavonarea at 2degreesnetwork.com> ?wrote:
>>>
>>> Hello,
>>>
>>> On my Ubuntu desktop, httplib2 v0.4.0 is installed system-wide because
>>> it's required by many things. However, I need to use v0.6.0 of that
>>> package in my Buildout-powered project.
>>>
>>> But when I run Buildout, I get this error:
>>> =====
>>> VersionConflict: (httplib2 0.4.0 (/usr/lib/pymodules/python2.5),
>>> Requirement.parse('httplib2==0.6.0'))
>>> =====
>>>
>>> I've hit this problem before and what I had done is to remove the
>>> system-wide install, which I cannot do this time.
>>>
>>> There has to be a way for Buildout to ignore the global install, but I
>>> could not find the answer after reading the documentation.
>>>
>>> Can you please help me?
>>
>> There isn't currently an option to get buildout to ignore
>> site-packages, although an option to do that is under review.

Will this option be able to disregard the system-wide
setuptools/Distribute? Some systems have old setuptools versions and
users are unable to update (or better said, uncomfortable with
updating). When we give them a package that has a newer bootstrap.py
(http://python-distribute.org/bootstrap.py for example), they can't
bootstrap the project.

And what does "under review" mean? Is there a development version of
bootstrap.py somewhere that we use to can try the new feature?

>> Many of us simply avoid using system Python installs. ?I personally
>> always have clean Python installs, independent from system Python,
>> that I use for applications.
>
> I hope you merge that option ASAP. :)
>
> The problem is not "us" who have pristine global Python's. It's "them" that
> we give our buildouts to and expect them to work the same as they did on our
> own machine: end users (Plone's installers are buildouts now, for example),
> sysadmins, and new developers.

I absolutely agree with Martin Aspeli here.

Bests,
Attila

From mbaiju at zeomega.com  Wed Mar 10 05:20:24 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Wed, 10 Mar 2010 09:50:24 +0530
Subject: [Distutils] use of '_' in package name causing version parsing
	issue?
In-Reply-To: <20100309222412.0ABB43A476B@sparrow.telecommunity.com>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<20100309222412.0ABB43A476B@sparrow.telecommunity.com>
Message-ID: <c911c70d1003092020w324999f2m7dcf9d5e7f403df0@mail.gmail.com>

On Wed, Mar 10, 2010 at 3:54 AM, P.J. Eby <pje at telecommunity.com> wrote:
> At 03:03 PM 3/9/2010 -0600, Brad Allen wrote:
>>
>> Today I was informed of an issue in which buildout (with the latest
>> setuptools) is not resolving version numbers properly, causing the
>> wrong package to be selected in some cases. The cause identified was
>> having '_' in the package name.
>
> I suspect there is a miscommunication or misunderstanding somewhere. ?It is
> perfectly acceptable to have a '_' in a package name or project name. ?This:
>
>> | >>> a="jiva_interface-2.3.6-py2.6.egg"
>> | >>> b="jiva_interface-2.3.8-py2.6.egg"
>> | >>> pkg_resources.parse_version(a)
>
> Is the wrong API to use to parse an egg filename, as parse_version() is for
> parsing a version that's already extracted from a filename. ?This is the
> right API for extracting a version from a filename:
>
>>>> pkg_resources.Distribution.from_filename(a).version
> '2.3.6'
>>>> pkg_resources.Distribution.from_filename(b).version
> '2.3.8'
>>>> pkg_resources.Distribution.from_filename(c).version
> '0.1.1'
>>>> pkg_resources.Distribution.from_filename(d).version
> '0.1.2'
>
> And here's the correct one for extracting the parsed version from a
> filename:
>
>>>> pkg_resources.Distribution.from_filename(a).parsed_version
> ('00000002', '00000003', '00000006', '*final')
>>>> pkg_resources.Distribution.from_filename(b).parsed_version
> ('00000002', '00000003', '00000008', '*final')
>>>> pkg_resources.Distribution.from_filename(c).parsed_version
> ('00000000', '00000001', '00000001', '*final')
>>>> pkg_resources.Distribution.from_filename(d).parsed_version
> ('00000000', '00000001', '00000002', '*final')
>
> As you can see, these APIs work just fine, so the example given is a red
> herring, unless Buildout is using the APIs incorrectly (which I really doubt
> it is).
>
> Usually, the situation where people run into trouble with unusual package
> names or filenames is when they produce a source distribution manually, or
> by using something other than distutils/setuptools (that has different
> filename escaping rules), or when they manually rename a file before
> uploading, and expect it to still work the same.
>
> It would be a good idea for you to check which of these things (if any) is
> taking place, and provide details of the specific problem, with steps to
> reproduce it, since the example given probably has nothing to do with it.

I spend some time with Buildout and setuptools code to identify the issue.
I will try to explain my findings.

1. Buildout is relying on pkg_resources.Requirement.parse function to
    get the "project_name" like this:

     pkg_resources.Requirement.parse('jiva_interface').project_name

    I can see from the code of `Requirement` class that, the `__init__`
    method is deprecated and recommend to use `parse`
    function. Does this mean that we should not use the attributes
    of an instance of `Requirement` class?  This is very important as
    the `parse` function return a list of instances of `Requirement` class.

   So, if it is acceptable to use the "project_name" attribute, then
   Buildout can rely on it, right ?

   Here is beginning of `Requirement` class:

    class Requirement:
        def __init__(self, project_name, specs, extras):
            """DO NOT CALL THIS UNDOCUMENTED METHOD; use Requirement.parse()!"""

2. This is the code which get the "project_name" in the same `__init__` method:

        self.unsafe_name, project_name = project_name, safe_name(project_name)
        self.project_name, self.key = project_name, project_name.lower()

    I looked at the "safe_name" method:

    def safe_name(name):
        """Convert an arbitrary string to a standard distribution name

        Any runs of non-alphanumeric/. characters are replaced with a
single '-'.
        """
        return re.sub('[^A-Za-z0-9.]+', '-', name)

   According to this code, this will be the result:

     pkg_resources.safe_name('jiva_interface')
     'jiva-interface'

   And:

     pkg_resources.Requirement.parse('jiva_interface').project_name
     'jiva-interface'

    Is this behavior correct ?

    If you think what setuptools doing is fine, we will make changes
    in Buildout code to use the "safe_name" method where ever it directly
    get "project_name".

Regards,
Baiju M

From WCoole at aperiogroup.com  Tue Mar  9 00:38:38 2010
From: WCoole at aperiogroup.com (Walter Coole)
Date: Mon, 8 Mar 2010 15:38:38 -0800
Subject: [Distutils] Newby Question: install easy_install for python2.5
	on RHEL
In-Reply-To: <20100306180650.6EC713A4077@sparrow.telecommunity.com>
References: <55AD1EEF173837488F4B56BEFC99B71C41D02D@server.aperiogroup.local>
	<20100306180650.6EC713A4077@sparrow.telecommunity.com>
Message-ID: <55AD1EEF173837488F4B56BEFC99B71C479409@server.aperiogroup.local>

Thanks, that was just the hint that I needed.  In case anyone else that
was struggling with this configuration, what I did was:

wget
http://bashton.com/downloads/rpm/python/python25-devel-2.5.1-bashton1.x8
6_64.rpm
sudo yum --nogpgcheck localinstall
python25-devel-2.5.1-bashton1.x86_64.rpm
sudo sh setuptools-0.6c11-py2.5.egg
sudo python2.5 ez_setup.py
...

Now the rest of the install is working (although my code still has a
unnecessary dependency for me to work out ;-( ).
Walter


-----Original Message-----
From: P.J. Eby [mailto:pje at telecommunity.com] 
Sent: Saturday, March 06, 2010 10:07 AM
To: Walter Coole; distutils-sig at python.org
Subject: Re: [Distutils] Newby Question: install easy_install for
python2.5 on RHEL

At 01:22 PM 3/2/2010 -0800, Walter Coole wrote:
>Content-Class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01CABA4E.86D76612"
>
>When I try to install with:
>
>                 sudo sh setuptools-0.6c11-py2.5.egg
>
>I get an error:
>
>                 error: invalid Python installation: unable to open 
> /usr/lib64/python2.5/config/Makefile (No such file or directory)
>
>That I don't really understand.  Yes, it's true that there is no 
>/usr/lib64/python2.5/config directory, but I've gotten along nicely 
>without one for quite a while.

You are probably missing your distribution's "python-dev" or 
"python-devel" package, which is required to use the distutils at 
all, let alone setuptools.




From yonsy at aureal.pe  Thu Mar 11 17:46:22 2010
From: yonsy at aureal.pe (Yonsy Solis)
Date: Thu, 11 Mar 2010 11:46:22 -0500
Subject: [Distutils] Buildout: Version conflicts with system-wide
 libraries
In-Reply-To: <4B99194E.5010205@2degreesnetwork.com>
References: <4B990D1B.5090807@2degreesnetwork.com>
	<1268324465.13354.3.camel@alisah>
	<4B99194E.5010205@2degreesnetwork.com>
Message-ID: <1268325982.13354.5.camel@alisah>

On Thu, 2010-03-11 at 16:24 +0000, Gustavo Narea wrote:

> Thanks, Yonsy. However I already do that :/

don't work ? strange, 

with --no-site-packages u have a totally isolated python ...

the same error happens ?


-- 
Yonsy Solis
Aureal Systems
(mov) 989-124-141
(www) http://www.aureal.pe



From yonsy at aureal.pe  Thu Mar 11 17:21:05 2010
From: yonsy at aureal.pe (Yonsy Solis)
Date: Thu, 11 Mar 2010 11:21:05 -0500
Subject: [Distutils] Buildout: Version conflicts with system-wide
 libraries
In-Reply-To: <4B990D1B.5090807@2degreesnetwork.com>
References: <4B990D1B.5090807@2degreesnetwork.com>
Message-ID: <1268324465.13354.3.camel@alisah>

On Thu, 2010-03-11 at 15:32 +0000, Gustavo Narea wrote:
> Hello,
> 
> On my Ubuntu desktop, httplib2 v0.4.0 is installed system-wide because
> it's required by many things. However, I need to use v0.6.0 of that
> package in my Buildout-powered project.
> 
> But when I run Buildout, I get this error:
> =====
> VersionConflict: (httplib2 0.4.0 (/usr/lib/pymodules/python2.5),
> Requirement.parse('httplib2==0.6.0'))
> =====
> 
> I've hit this problem before and what I had done is to remove the
> system-wide install, which I cannot do this time.
> 
> There has to be a way for Buildout to ignore the global install, but I
> could not find the answer after reading the documentation.

use virtualenv with --no-site-packages option, and run your buildout
with the python from your virtualenv

http://pypi.python.org/pypi/virtualenv

-- 
Yonsy Solis
Aureal Systems
(mov) 989-124-141
(www) http://www.aureal.pe



From sdouche at gmail.com  Thu Mar 11 20:45:44 2010
From: sdouche at gmail.com (Sebastien Douche)
Date: Thu, 11 Mar 2010 20:45:44 +0100
Subject: [Distutils] Buildout: Version conflicts with system-wide
	libraries
In-Reply-To: <1268325982.13354.5.camel@alisah>
References: <4B990D1B.5090807@2degreesnetwork.com>
	<1268324465.13354.3.camel@alisah> 
	<4B99194E.5010205@2degreesnetwork.com>
	<1268325982.13354.5.camel@alisah>
Message-ID: <5e1183fa1003111145t6769c411n6f14281d9ffd8aa1@mail.gmail.com>

On Thu, Mar 11, 2010 at 17:46, Yonsy Solis <yonsy at aureal.pe> wrote:
> with --no-site-packages u have a totally isolated python ...

Totally isolated? Not really. The only solution is, like Jim said, to
install a new Python[1].



[1] Basic steps :
- install the package build-essential
- download the source package
- tar xvfz <package> ; cd <package> ; ./configure --prefix=/your/path;
make; make install



-- 
Sebastien Douche <sdouche at gmail.com>
Twitter: http://bit.ly/afkrK (agile, python, open source)

From jim at zope.com  Thu Mar 11 21:36:14 2010
From: jim at zope.com (Jim Fulton)
Date: Thu, 11 Mar 2010 15:36:14 -0500
Subject: [Distutils] Buildout: Version conflicts with system-wide
	libraries
In-Reply-To: <1da06521003110844y30ab997fmc072e78c95fe70cd@mail.gmail.com>
References: <4B990D1B.5090807@2degreesnetwork.com>
	<1099b90b1003110800me2d26ecxbf9e914d5c71a1f@mail.gmail.com> 
	<hnb4ts$3s9$1@dough.gmane.org>
	<1da06521003110844y30ab997fmc072e78c95fe70cd@mail.gmail.com>
Message-ID: <1099b90b1003111236o4cdd76f0u5c7db081f96702c@mail.gmail.com>

On Thu, Mar 11, 2010 at 11:44 AM, Attila Ol?h <attilaolah at gmail.com> wrote:
...
>>> There isn't currently an option to get buildout to ignore
>>> site-packages, although an option to do that is under review.
>
> Will this option be able to disregard the system-wide
> setuptools/Distribute?

Yes.

...

> And what does "under review" mean? Is there a development version of
> bootstrap.py somewhere that we use to can try the new feature?

It means that there is a branch with the change that I need to review and merge.

Jim

-- 
Jim Fulton

From mbaiju at zeomega.com  Fri Mar 12 07:12:07 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Fri, 12 Mar 2010 11:42:07 +0530
Subject: [Distutils] use of '_' in package name causing version parsing
	issue?
In-Reply-To: <20100311154303.A45613A40AF@sparrow.telecommunity.com>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<20100309222412.0ABB43A476B@sparrow.telecommunity.com>
	<c911c70d1003092020w324999f2m7dcf9d5e7f403df0@mail.gmail.com>
	<20100311043920.6B0433A4062@sparrow.telecommunity.com>
	<c911c70d1003102135y2dd53c5eia0514cb9dac7b575@mail.gmail.com>
	<c911c70d1003102308h62908555gf8408f40429f99c9@mail.gmail.com>
	<20100311154303.A45613A40AF@sparrow.telecommunity.com>
Message-ID: <c911c70d1003112212n6097a86eg9f71eb046b1db16d@mail.gmail.com>

On Thu, Mar 11, 2010 at 9:13 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 12:38 PM 3/11/2010 +0530, Baiju M wrote:
>>
>> On Thu, Mar 11, 2010 at 11:05 AM, Baiju M <mbaiju at zeomega.com> wrote:
>> > If "_" is a valid project_name identifier, why it is replaces with "-" ?
>
> In order to have a canonicalized name form which can be escaped in filenames
> for unambiguous identification of an egg's project and version.
>
> Egg filenames use '-' as a separator between name, version, python version,
> and platform. ?A '-' in any of these components is escaped as '_', so that
> the '-' remains a viable and unambiguous separator. ?This means that '_'
> gets turned back into a '-' when unescaped, so the mapping between '_' and
> '-' is part of the safe_name canonical form.

Sorry, I confused.

Then, why "_" was added as a valid project name identifier ?

Regards,
Baiju M

From pje at telecommunity.com  Fri Mar 12 18:00:18 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 12 Mar 2010 12:00:18 -0500
Subject: [Distutils] use of '_' in package name causing version parsing
 issue?
In-Reply-To: <c911c70d1003112212n6097a86eg9f71eb046b1db16d@mail.gmail.co
 m>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<20100309222412.0ABB43A476B@sparrow.telecommunity.com>
	<c911c70d1003092020w324999f2m7dcf9d5e7f403df0@mail.gmail.com>
	<20100311043920.6B0433A4062@sparrow.telecommunity.com>
	<c911c70d1003102135y2dd53c5eia0514cb9dac7b575@mail.gmail.com>
	<c911c70d1003102308h62908555gf8408f40429f99c9@mail.gmail.com>
	<20100311154303.A45613A40AF@sparrow.telecommunity.com>
	<c911c70d1003112212n6097a86eg9f71eb046b1db16d@mail.gmail.com>
Message-ID: <20100312170018.5D3343A4062@sparrow.telecommunity.com>

At 11:42 AM 3/12/2010 +0530, Baiju M wrote:
>On Thu, Mar 11, 2010 at 9:13 PM, P.J. Eby <pje at telecommunity.com> wrote:
> > At 12:38 PM 3/11/2010 +0530, Baiju M wrote:
> >>
> >> On Thu, Mar 11, 2010 at 11:05 AM, Baiju M <mbaiju at zeomega.com> wrote:
> >> > If "_" is a valid project_name identifier, why it is replaces with "-" ?
> >
> > In order to have a canonicalized name form which can be escaped 
> in filenames
> > for unambiguous identification of an egg's project and version.
> >
> > Egg filenames use '-' as a separator between name, version, python version,
> > and platform.  A '-' in any of these components is escaped as '_', so that
> > the '-' remains a viable and unambiguous separator.  This means that '_'
> > gets turned back into a '-' when unescaped, so the mapping between '_' and
> > '-' is part of the safe_name canonical form.
>
>Sorry, I confused.
>
>Then, why "_" was added as a valid project name identifier ?

It's a valid project name character; what it's not is a *canonical* 
project name character.


From jim at zope.com  Fri Mar 12 21:08:53 2010
From: jim at zope.com (Jim Fulton)
Date: Fri, 12 Mar 2010 15:08:53 -0500
Subject: [Distutils] use of '_' in package name causing version parsing
	issue?
In-Reply-To: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
Message-ID: <1099b90b1003121208t2d8bc45aj29af6f3640b0f0e5@mail.gmail.com>

On Tue, Mar 9, 2010 at 4:03 PM, Brad Allen <bradallen137 at gmail.com> wrote:
> Today I was informed of an issue in which buildout (with the latest
> setuptools) is not resolving version numbers properly, causing the
> wrong package to be selected in some cases. The cause identified was
> having '_' in the package name. I am still investigating this issue,
> but thought it would be worth mentioning on the list in case anyone
> had a quick answer.
>
> Here is the note I received which raised the issue:

Sorry, I didn't realize that this thread was about buildout.

Brad, could you send me a simple buildout.cfg (ideally one that
installs one project) that illustrates the problem and I'll dig into
it.

Jim

-- 
Jim Fulton

From regebro at gmail.com  Fri Mar 12 21:20:10 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 12 Mar 2010 21:20:10 +0100
Subject: [Distutils] Pypy and site.py and makepath
Message-ID: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>

What exactly is site.py for? I tried installing Distribute with PyPy,
and it fails, because if you start it, it runs site.py, and site.py
uses makepath, but doesn't import or define it, so it fails.

Running the tests with python2.6 and it seems site.py is never run,
but removing it makes the tests fail.

Any insight into this?

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Fri Mar 12 21:29:40 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 12 Mar 2010 15:29:40 -0500
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
Message-ID: <94bdd2611003121229y8136281r4a306babbbaf461c@mail.gmail.com>

On Fri, Mar 12, 2010 at 3:20 PM, Lennart Regebro <regebro at gmail.com> wrote:
> What exactly is site.py for?

site.py is run when your interpreter starts. It loads a few things in
the builtins, and add some paths
in sys.path (like per-user paths, etc)

> I tried installing Distribute with PyPy,
> and it fails, because if you start it, it runs site.py, and site.py
> uses makepath, but doesn't import or define it, so it fails.
>
> Running the tests with python2.6 and it seems site.py is never run,
> but removing it makes the tests fail.
>
> Any insight into this?
>

the tests in py26 at CPYthon definitely runs site.py, but since its
before the interpreter is fully available, I am not sure if you can
trace it easily.

now for PyPy, I am not sure how the stdlib works with it. Isn't that forked ?


> --
> Lennart Regebro: Python, Zope, Plone, Grok
> http://regebro.wordpress.com/
> +33 661 58 14 64
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From guido at python.org  Sat Mar 13 00:35:02 2010
From: guido at python.org (Guido van Rossum)
Date: Fri, 12 Mar 2010 15:35:02 -0800
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
Message-ID: <ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>

On Fri, Mar 12, 2010 at 12:20 PM, Lennart Regebro <regebro at gmail.com> wrote:
> What exactly is site.py for? I tried installing Distribute with PyPy,
> and it fails, because if you start it, it runs site.py, and site.py
> uses makepath, but doesn't import or define it, so it fails.

Eh? I see

def makepath(*paths):
    dir = os.path.abspath(os.path.join(*paths))
    return dir, os.path.normcase(dir)

around line 75 of site.py in the python 2.6 source tree. Maybe PyPy
has its own broken copy?

> Running the tests with python2.6 and it seems site.py is never run,

How do you know?

> but removing it makes the tests fail.
>
> Any insight into this?

-- 
--Guido van Rossum (python.org/~guido)

From regebro at gmail.com  Sat Mar 13 00:45:23 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 13 Mar 2010 00:45:23 +0100
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
Message-ID: <319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.com>

On Sat, Mar 13, 2010 at 00:35, Guido van Rossum <guido at python.org> wrote:
> around line 75 of site.py in the python 2.6 source tree. Maybe PyPy
> has its own broken copy?

No, it's the site.py in the Distribute tree I'm talking about. Sorry
for being unclear about this. It may be a broken copy, yes.

>> Running the tests with python2.6 and it seems site.py is never run,
>
> How do you know?

Because no matter what I stick in it, prints, exceptions, set_trace(),
syntax errors; nothing happens.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From pje at telecommunity.com  Sat Mar 13 01:54:52 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 12 Mar 2010 19:54:52 -0500
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.co
 m>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
	<319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.com>
Message-ID: <20100313005452.B97663A4062@sparrow.telecommunity.com>

At 12:45 AM 3/13/2010 +0100, Lennart Regebro wrote:
>No, it's the site.py in the Distribute tree I'm talking about. Sorry
>for being unclear about this. It may be a broken copy, yes.

Since distribute is a fork of the 0.6 branch of setuptools, it's 
presumably the special site.py loader (called 
setuptools/site-patch.py in the 0.7 trunk) that's used for making 
PYTHONPATH directories support .pth files.  It's placed in PYTHONPATH 
directories used with easy_install, and it expects to find another 
'site' module loadable on sys.path.

It was done this way because it needed to see an unmangled sys.path 
before the site module gets a hold of it, and because it couldn't 
simply *replace* the site module without interfering with Linux 
distro-specific patches to the site module to add in additional 
site-package directories in various nonstandard ways that would be 
better done in .pth files to begin with.  ;-)

Anyway, if PyPy includes a precompiled or "builtin" site module of 
some kind, it's unlikely that the patch file would work correctly, 
even if PyPy allows executing a custom site.py.


From regebro at gmail.com  Sat Mar 13 10:13:23 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 13 Mar 2010 10:13:23 +0100
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <20100313005452.B97663A4062@sparrow.telecommunity.com>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
	<319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.com>
	<20100313005452.B97663A4062@sparrow.telecommunity.com>
Message-ID: <319e029f1003130113h7fa5ae49na1ec8d59711bcc2c@mail.gmail.com>

On Sat, Mar 13, 2010 at 01:54, P.J. Eby <pje at telecommunity.com> wrote:
> Anyway, if PyPy includes a precompiled or "builtin" site module of some
> kind, it's unlikely that the patch file would work correctly, even if PyPy
> allows executing a custom site.py.

Well, I don't know if it does, but adding the makepath method from
Pythons site.py seems to solve that problem anyway, and you get other
errors. I don't have time to look into this very deeply, but
Distribute/Setuptools seems to be a good test for cross-platform
compatibility as it involves much magic. :)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Sat Mar 13 10:49:48 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 13 Mar 2010 10:49:48 +0100
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <319e029f1003130113h7fa5ae49na1ec8d59711bcc2c@mail.gmail.com>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
	<319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.com>
	<20100313005452.B97663A4062@sparrow.telecommunity.com>
	<319e029f1003130113h7fa5ae49na1ec8d59711bcc2c@mail.gmail.com>
Message-ID: <319e029f1003130149u6492426aj8931e67e39ad5d75@mail.gmail.com>

On Sat, Mar 13, 2010 at 10:13, Lennart Regebro <regebro at gmail.com> wrote:
> Well, I don't know if it does, but adding the makepath method from
> Pythons site.py seems to solve that problem anyway, and you get other
> errors. I don't have time to look into this very deeply, but
> Distribute/Setuptools seems to be a good test for cross-platform
> compatibility as it involves much magic. :)

Well, PyPy distutils.sysconfig does not have a customize_compiler, so
it breaks there anyway.

But I realized something more: Could it be that in CPython, Pythons
site.py is read in first and that context is retained when running a
local site.py? Because now I again get the error that another method
is missing (addsitedir) which does exist in Pythons site.py. It exists
in PyPy's site.py as well, but not in distributes site.py.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From pje at telecommunity.com  Sat Mar 13 16:07:41 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 13 Mar 2010 10:07:41 -0500
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <319e029f1003130149u6492426aj8931e67e39ad5d75@mail.gmail.co
 m>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
	<319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.com>
	<20100313005452.B97663A4062@sparrow.telecommunity.com>
	<319e029f1003130113h7fa5ae49na1ec8d59711bcc2c@mail.gmail.com>
	<319e029f1003130149u6492426aj8931e67e39ad5d75@mail.gmail.com>
Message-ID: <20100313150743.3D9703A4062@sparrow.telecommunity.com>

At 10:49 AM 3/13/2010 +0100, Lennart Regebro wrote:
>On Sat, Mar 13, 2010 at 10:13, Lennart Regebro <regebro at gmail.com> wrote:
> > Well, I don't know if it does, but adding the makepath method from
> > Pythons site.py seems to solve that problem anyway, and you get other
> > errors. I don't have time to look into this very deeply, but
> > Distribute/Setuptools seems to be a good test for cross-platform
> > compatibility as it involves much magic. :)
>
>Well, PyPy distutils.sysconfig does not have a customize_compiler, so
>it breaks there anyway.
>
>But I realized something more: Could it be that in CPython, Pythons
>site.py is read in first and that context is retained when running a
>local site.py?

No.  The site-patch code explicitly finds and loads the old module 
into the same namespace, in order to avoid the compatibility issues I 
mentioned previously.  (i.e., some distros patch the site module to 
add custom site paths, despite the fact that the whole purpose of 
.pth files is to make it so you *don't* have to patch site.py to add 
such paths!)


>Because now I again get the error that another method
>is missing (addsitedir) which does exist in Pythons site.py. It exists
>in PyPy's site.py as well, but not in distributes site.py.

Here are some possible ways you could get that behavior:

1. site-patch cannot load PyPy's built-in site module, and is instead 
finding an *empty* site.py on sys.path after it, OR

2. It is finding a valid site.py, but the standard import protocols 
(i.e., imp.find_module/load_module and 
path_importer_cache[modulename].load_module()) are not working 
correctly when called on an existing module.

If you trace the execution of the site-patch to whichever load_module 
line is getting run, and print the value of the 'item' variable, 
you'll see what path entry the "original" site is being discovered 
in, and you'll then be able to tell which of the above possibilities applies.

(Offhand, I'd guess that the import bug is perhaps a bit more likely; 
the reloading behavior of loaders and imp is a little on the obscure 
side and might not be sufficiently covered by the stdlib or PyPy 
tests.  The likely failure is that some piece of code is returning a 
*new* module object, rather than updating the existing one as PEP 302 
requires.)


From regebro at gmail.com  Sat Mar 13 17:42:15 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 13 Mar 2010 17:42:15 +0100
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <20100313150743.3D9703A4062@sparrow.telecommunity.com>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
	<319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.com>
	<20100313005452.B97663A4062@sparrow.telecommunity.com>
	<319e029f1003130113h7fa5ae49na1ec8d59711bcc2c@mail.gmail.com>
	<319e029f1003130149u6492426aj8931e67e39ad5d75@mail.gmail.com>
	<20100313150743.3D9703A4062@sparrow.telecommunity.com>
Message-ID: <319e029f1003130842v5af262bcwafffac89ae1fbbf@mail.gmail.com>

On Sat, Mar 13, 2010 at 16:07, P.J. Eby <pje at telecommunity.com> wrote:
> 2. It is finding a valid site.py, but the standard import protocols (i.e.,
> imp.find_module/load_module and
> path_importer_cache[modulename].load_module()) are not working correctly
> when called on an existing module.

Yeah, this seems like the problem. It imports it, but neither globals
or locals change. It's hard to say exactly what the problem is as I
can't debug what happens in CPython, as no matter what I put into the
local site.py, nothing seems to happen. So I't hard to me to check
what the behaviour *should* be, but it seems clear that this is where
the difference is.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From regebro at gmail.com  Sat Mar 13 17:54:35 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 13 Mar 2010 17:54:35 +0100
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <319e029f1003130842v5af262bcwafffac89ae1fbbf@mail.gmail.com>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
	<319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.com>
	<20100313005452.B97663A4062@sparrow.telecommunity.com>
	<319e029f1003130113h7fa5ae49na1ec8d59711bcc2c@mail.gmail.com>
	<319e029f1003130149u6492426aj8931e67e39ad5d75@mail.gmail.com>
	<20100313150743.3D9703A4062@sparrow.telecommunity.com>
	<319e029f1003130842v5af262bcwafffac89ae1fbbf@mail.gmail.com>
Message-ID: <319e029f1003130854n3ac90383ic9379a0e8bc27373@mail.gmail.com>

On Sat, Mar 13, 2010 at 17:42, Lennart Regebro <regebro at gmail.com> wrote:
> On Sat, Mar 13, 2010 at 16:07, P.J. Eby <pje at telecommunity.com> wrote:
>> 2. It is finding a valid site.py, but the standard import protocols (i.e.,
>> imp.find_module/load_module and
>> path_importer_cache[modulename].load_module()) are not working correctly
>> when called on an existing module.
>
> Yeah, this seems like the problem. It imports it, but neither globals
> or locals change. It's hard to say exactly what the problem is as I
> can't debug what happens in CPython, as no matter what I put into the
> local site.py, nothing seems to happen. So I't hard to me to check
> what the behaviour *should* be, but it seems clear that this is where
> the difference is.

Actually, I suddenly remembered -v, and ran python -v. and the local
site.py is *not* being imported, which explains why no matter what I
write in it it gets ignored. So there seems to be at least two
differences here.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Sat Mar 13 18:07:45 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 13 Mar 2010 12:07:45 -0500
Subject: [Distutils] RFC: enhanced file list description for Distutils (PEP
	376 extension)
Message-ID: <94bdd2611003130907o1858bcfcq626f346eac1e4440@mail.gmail.com>

Hello,


We worked during the Pycon sprint on PEP 376. The goal was to finish
the section about the RECORD file syntax. This file contains the list
of installed files when a project is installed using distutils (and
distutils-based tools.)

For all the files that are supposed to land in the Python tree on the
system, like Python modules, it's pretty clear and simple. The fuzzy
part in distutils has always been about resource files (configuration
files, help files, etc.) that should land on specific locations on the
target system if we want to be FHS-compliant.

We ended up working on something bigger for that. We wanted to make it
easier for developer to describe what their projects contain, and
easier for OS packagers to place resources files of a project in the
proper location.

For instance, a ini-file in your Foo project, called foo.cfg, should
land in /etc/ under Debian. From a developer point of view, the
location of the file on the target system doesn't really matter as
long as he can reach it somehow in its code. People that want a
generic solution put that file in the source tree and use __file__ to
find the path. That is not really robust and doesn't work if the
source tree is in a zip file for instance. Setuptools provides an api
for that, but the resource cannot be relocated on the system by the
packagers.

We worked on a solution to make life easier for developers and
packagers. IOW, let the packager define the paths of the files on the
system, and provide an API for the developer to get the file back.

Proposal
------------

Here's the proposal :

1. A ``resources`` section in ``setup.cfg`` that maps resource files
to their categories (and optionally subdirectory prefixes within those
categories)

2. A ``sysconfig.cfg`` file at the system Python level that maps
categories to a position on the filesystem

3. A simple ``pkgutil.open()`` API to access resources from code

Please read the full detailed proposal here :
http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst, and
comment ! :)


Calendar
------------

I am working on finishing some details at the end of the proposal, but
the document is already readable (the unfinished parts are after the
API section).

If we can manage to finish the discussion on this in the upcoming
weeks and get it accepted by Guido, we could include in 2.7 a
sysconfig.cfg file that is used by the existing sysconfig.py APIs
(right now it is using a python dict for the paths), and add APIs in
pkgutil.

If we finish this work too late, (which is most likely to be the case
because 2.7b1 is due in a few weeks), we will add these APIs in
distutils2 I guess, and see if we can add them in the next version of
3.x (or 2.8 ;) )

Regards,
Tarek

-- 
Tarek Ziad? | http://ziade.org

From pje at telecommunity.com  Sat Mar 13 18:11:12 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 13 Mar 2010 12:11:12 -0500
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <319e029f1003130842v5af262bcwafffac89ae1fbbf@mail.gmail.com
 >
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
	<319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.com>
	<20100313005452.B97663A4062@sparrow.telecommunity.com>
	<319e029f1003130113h7fa5ae49na1ec8d59711bcc2c@mail.gmail.com>
	<319e029f1003130149u6492426aj8931e67e39ad5d75@mail.gmail.com>
	<20100313150743.3D9703A4062@sparrow.telecommunity.com>
	<319e029f1003130842v5af262bcwafffac89ae1fbbf@mail.gmail.com>
Message-ID: <20100313171113.C33833A40A7@sparrow.telecommunity.com>

At 05:42 PM 3/13/2010 +0100, Lennart Regebro wrote:
>On Sat, Mar 13, 2010 at 16:07, P.J. Eby <pje at telecommunity.com> wrote:
> > 2. It is finding a valid site.py, but the standard import protocols (i.e.,
> > imp.find_module/load_module and
> > path_importer_cache[modulename].load_module()) are not working correctly
> > when called on an existing module.
>
>Yeah, this seems like the problem. It imports it, but neither globals
>or locals change. It's hard to say exactly what the problem is as I
>can't debug what happens in CPython, as no matter what I put into the
>local site.py, nothing seems to happen. So I't hard to me to check
>what the behaviour *should* be, but it seems clear that this is where
>the difference is.

What the behavior should be is that when you call load_module (either 
on an importer instance or the imp.load_module function), and the 
module already exists in sys.modules, that's the module object that 
should be updated.  reload() relies on this, as do various other 
things such as lazy importing tools.

A quick glance at PyPy's source (at 
http://codespeak.net/pypy/dist/pypy/module/imp/ ) reveals that it 
does support reusing a module in sys.modules, but for some reason 
this code is shut off by a keyword argument that defaults to 
false.  This behavior is *definitely* not what CPython's load_module does.

I didn't dig into whether this is also true for any importers that 
PyPy might put into the path importer cache, but it's definitely true 
for imp.load_module.

One could argue, I suppose, whether the imp behavior is official 
Python spec vs. CPython-only feature, but setuptools isn't the only 
thing that relies on it, and PEP 302 *does* makes the reuse behavior 
explicitly required for loader objects.  Also, its absence would make 
it bloody hard (probably impossible, actually) to implement a 
reload() function (either the base one or an improved version) in 
terms of the imp API.

Simplest fix for this in PyPy would probably be to change 
load_module() in modules.imp.interp_inp to call 
importing.load_module() with the 'reuse' argument set to True.  A 
test for this behavior is straightforward: stick a module object into 
sys.modules with a variable set, then use load_module() to load 
something that sets another variable, then check that both variables 
are set in the module.

(Also, it should assert that load_module() returns the module object 
that was *already* in sys.modules, rather than that it just shoved a 
new module into sys.modules -- which is what the current PyPy code 
apparently does.)


From pje at telecommunity.com  Sat Mar 13 18:25:50 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 13 Mar 2010 12:25:50 -0500
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <319e029f1003130854n3ac90383ic9379a0e8bc27373@mail.gmail.co
 m>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
	<319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.com>
	<20100313005452.B97663A4062@sparrow.telecommunity.com>
	<319e029f1003130113h7fa5ae49na1ec8d59711bcc2c@mail.gmail.com>
	<319e029f1003130149u6492426aj8931e67e39ad5d75@mail.gmail.com>
	<20100313150743.3D9703A4062@sparrow.telecommunity.com>
	<319e029f1003130842v5af262bcwafffac89ae1fbbf@mail.gmail.com>
	<319e029f1003130854n3ac90383ic9379a0e8bc27373@mail.gmail.com>
Message-ID: <20100313172552.3D2963A40A7@sparrow.telecommunity.com>

At 05:54 PM 3/13/2010 +0100, Lennart Regebro wrote:
>On Sat, Mar 13, 2010 at 17:42, Lennart Regebro <regebro at gmail.com> wrote:
> > On Sat, Mar 13, 2010 at 16:07, P.J. Eby <pje at telecommunity.com> wrote:
> >> 2. It is finding a valid site.py, but the standard import protocols (i.e.,
> >> imp.find_module/load_module and
> >> path_importer_cache[modulename].load_module()) are not working correctly
> >> when called on an existing module.
> >
> > Yeah, this seems like the problem. It imports it, but neither globals
> > or locals change. It's hard to say exactly what the problem is as I
> > can't debug what happens in CPython, as no matter what I put into the
> > local site.py, nothing seems to happen. So I't hard to me to check
> > what the behaviour *should* be, but it seems clear that this is where
> > the difference is.
>
>Actually, I suddenly remembered -v, and ran python -v. and the local
>site.py is *not* being imported, which explains why no matter what I
>write in it it gets ignored. So there seems to be at least two
>differences here.

Perhaps PyPy also has an optimization that makes it use a built-in 
version of site.py, instead of using standard import logic.  Finding 
that would be a bit harder than tracking down the imp problem, 
though, as it doesn't appear that site is a "builtin" in PyPy the way 
imp is.  It does appear to be imported by 
http://codespeak.net/pypy/dist/pypy/bin/py.py however.

(I'm assuming, btw, that by "local site.py" you mean the patching 
site.py, not a site.py located in say, PyPy's site-packages directory.)


From regebro at gmail.com  Sat Mar 13 18:32:43 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sat, 13 Mar 2010 18:32:43 +0100
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <20100313172552.3D2963A40A7@sparrow.telecommunity.com>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
	<319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.com>
	<20100313005452.B97663A4062@sparrow.telecommunity.com>
	<319e029f1003130113h7fa5ae49na1ec8d59711bcc2c@mail.gmail.com>
	<319e029f1003130149u6492426aj8931e67e39ad5d75@mail.gmail.com>
	<20100313150743.3D9703A4062@sparrow.telecommunity.com>
	<319e029f1003130842v5af262bcwafffac89ae1fbbf@mail.gmail.com>
	<319e029f1003130854n3ac90383ic9379a0e8bc27373@mail.gmail.com>
	<20100313172552.3D2963A40A7@sparrow.telecommunity.com>
Message-ID: <319e029f1003130932u7a703796od2ed59a2c724d97d@mail.gmail.com>

On Sat, Mar 13, 2010 at 18:25, P.J. Eby <pje at telecommunity.com> wrote:
>> Actually, I suddenly remembered -v, and ran python -v. and the local
>> site.py is *not* being imported, which explains why no matter what I
>> write in it it gets ignored. So there seems to be at least two
>> differences here.
>
> Perhaps PyPy also has an optimization that makes it use a built-in version
> of site.py, instead of using standard import logic. ?Finding that would be a
> bit harder than tracking down the imp problem, though, as it doesn't appear
> that site is a "builtin" in PyPy the way imp is. ?It does appear to be
> imported by http://codespeak.net/pypy/dist/pypy/bin/py.py however.
>
> (I'm assuming, btw, that by "local site.py" you mean the patching site.py,
> not a site.py located in say, PyPy's site-packages directory.)

Right, I mean the one in the Distribute root. When starting pypy in
the distribute directory, it will load the site.py, and try to
"imp.load_module('site',stream,path,descr)". As you meantion, that
doesn't actually seem to do anything.

When starting CPython in the distribute directory, the local site.py is ignored.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From pje at telecommunity.com  Sat Mar 13 20:22:42 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 13 Mar 2010 14:22:42 -0500
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <319e029f1003130932u7a703796od2ed59a2c724d97d@mail.gmail.co
 m>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<ca471dc21003121535r7a84a171ica66871aeee6a900@mail.gmail.com>
	<319e029f1003121545k59f0bc91t36c3716bed03f389@mail.gmail.com>
	<20100313005452.B97663A4062@sparrow.telecommunity.com>
	<319e029f1003130113h7fa5ae49na1ec8d59711bcc2c@mail.gmail.com>
	<319e029f1003130149u6492426aj8931e67e39ad5d75@mail.gmail.com>
	<20100313150743.3D9703A4062@sparrow.telecommunity.com>
	<319e029f1003130842v5af262bcwafffac89ae1fbbf@mail.gmail.com>
	<319e029f1003130854n3ac90383ic9379a0e8bc27373@mail.gmail.com>
	<20100313172552.3D2963A40A7@sparrow.telecommunity.com>
	<319e029f1003130932u7a703796od2ed59a2c724d97d@mail.gmail.com>
Message-ID: <20100313192243.903B23A40A7@sparrow.telecommunity.com>

At 06:32 PM 3/13/2010 +0100, Lennart Regebro wrote:
>On Sat, Mar 13, 2010 at 18:25, P.J. Eby <pje at telecommunity.com> wrote:
> >> Actually, I suddenly remembered -v, and ran python -v. and the local
> >> site.py is *not* being imported, which explains why no matter what I
> >> write in it it gets ignored. So there seems to be at least two
> >> differences here.
> >
> > Perhaps PyPy also has an optimization that makes it use a built-in version
> > of site.py, instead of using standard import logic.  Finding that 
> would be a
> > bit harder than tracking down the imp problem, though, as it doesn't appear
> > that site is a "builtin" in PyPy the way imp is.  It does appear to be
> > imported by http://codespeak.net/pypy/dist/pypy/bin/py.py however.
> >
> > (I'm assuming, btw, that by "local site.py" you mean the patching site.py,
> > not a site.py located in say, PyPy's site-packages directory.)
>
>Right, I mean the one in the Distribute root. When starting pypy in
>the distribute directory, it will load the site.py, and try to
>"imp.load_module('site',stream,path,descr)". As you meantion, that
>doesn't actually seem to do anything.
>
>When starting CPython in the distribute directory, the local site.py 
>is ignored.

Interesting; that seems like an odd point of difference.  Perhaps the 
'' is added to sys.path later in CPython than it is in PyPy.

(In any case, that 'site.py in the Distribute root' (aka setuptools' 
site-patch.py) is only intended to be executed when it's in a 
PYTHONPATH directory.)


From nick at petangent.net  Sun Mar 14 11:16:32 2010
From: nick at petangent.net (Nicholas Bower)
Date: Sun, 14 Mar 2010 21:16:32 +1100
Subject: [Distutils] setuptools dependencies failure and wildcards
Message-ID: <59ce37421003140316s30530ac0gd4a43f00b3cec00b@mail.gmail.com>

I have the following simple dependencies using setuptools;

?? ? ?install_requires=['shapely==1.0.14','sqlalchemy==0.5.8'],

Two questions;

1) Shapely will not work. ?The available packages are;

Shapely-1.0.14.win32.py24.exe?(md5).
Shapely-1.0.14.win32.py25.exe?(md5).
Shapely-1.0.14.win32.py26.exe?(md5).

but python version is not being appended as below.  Is shapely thus
incompatible with setuptools?  If so, what are the name conventions
the author should be using and when does setuptools try for the
current python version only?

Searching for shapely==1.0.14
Reading http://pypi.python.org/simple/shapely/
Reading http://trac.gispython.org/projects/PCL/wiki/Shapely
Reading http://trac.gispython.org/projects/PCL/wiki/ShapeLy
Best match: Shapely 1.0.14
Downloading http://pypi.python.org/packages/2.5/S/Shapely/Shapely-1.0.14.win32.e
xe#md5=92281555b23623b8cf7b4fbc9d01f17a
error: Can't download
http://pypi.python.org/packages/2.5/S/Shapely/Shapely-1.0.14.win32.exe:
404 Not Found


2) How does one say "the latest release of sqlalchemy 0.5.x".
Unfortunately <0.6 picks up 0.6beta and I can see no way to do
wildcards in the docs and just say "give me the latest 0.5 series".

Thanks, Nick

From regebro at gmail.com  Sun Mar 14 11:27:12 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 14 Mar 2010 11:27:12 +0100
Subject: [Distutils] Pypy and site.py and makepath
In-Reply-To: <20100313192243.903B23A40A7@sparrow.telecommunity.com>
References: <319e029f1003121220q705d4fdu33a4109fe2b789a1@mail.gmail.com>
	<20100313005452.B97663A4062@sparrow.telecommunity.com>
	<319e029f1003130113h7fa5ae49na1ec8d59711bcc2c@mail.gmail.com>
	<319e029f1003130149u6492426aj8931e67e39ad5d75@mail.gmail.com>
	<20100313150743.3D9703A4062@sparrow.telecommunity.com>
	<319e029f1003130842v5af262bcwafffac89ae1fbbf@mail.gmail.com>
	<319e029f1003130854n3ac90383ic9379a0e8bc27373@mail.gmail.com>
	<20100313172552.3D2963A40A7@sparrow.telecommunity.com>
	<319e029f1003130932u7a703796od2ed59a2c724d97d@mail.gmail.com>
	<20100313192243.903B23A40A7@sparrow.telecommunity.com>
Message-ID: <319e029f1003140327x59bd2f2aqe90db5c1f04f76db@mail.gmail.com>

On Sat, Mar 13, 2010 at 20:22, P.J. Eby <pje at telecommunity.com> wrote:
> (In any case, that 'site.py in the Distribute root' (aka setuptools'
> site-patch.py) is only intended to be executed when it's in a PYTHONPATH
> directory.)

I reported that as a bug in PyPy, and also mentioned the False keyword
default on chat. They were already targetting distribute/setuptools
for the next release.
The next problem encountered in the tests is that PyPy of course have
no support for compiling C-extensions, so we'll need to add
conditionals for that I guess. But that's for some other day. :)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From hanno at hannosch.eu  Sun Mar 14 12:11:05 2010
From: hanno at hannosch.eu (Hanno Schlichting)
Date: Sun, 14 Mar 2010 12:11:05 +0100
Subject: [Distutils] setuptools dependencies failure and wildcards
In-Reply-To: <59ce37421003140316s30530ac0gd4a43f00b3cec00b@mail.gmail.com>
References: <59ce37421003140316s30530ac0gd4a43f00b3cec00b@mail.gmail.com>
Message-ID: <5cae42b21003140411q53d3ef84sd1f905ec8f4a4a2d@mail.gmail.com>

On Sun, Mar 14, 2010 at 11:16 AM, Nicholas Bower <nick at petangent.net> wrote:
> 1) Shapely will not work. ?The available packages are;

[..] can't help with this question

> 2) How does one say "the latest release of sqlalchemy 0.5.x".
> Unfortunately <0.6 picks up 0.6beta and I can see no way to do
> wildcards in the docs and just say "give me the latest 0.5 series".

You can specify:

<0.6dev

which excludes any development and pre-final versions of the 0.6
series. If that looks strange to you, you could also say:

<0.5.999

assuming it is unlikely the package ever gets a 999 maintenance release.

Hanno

From pje at telecommunity.com  Sun Mar 14 17:18:27 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 14 Mar 2010 12:18:27 -0400
Subject: [Distutils] setuptools dependencies failure and wildcards
In-Reply-To: <59ce37421003140316s30530ac0gd4a43f00b3cec00b@mail.gmail.co
 m>
References: <59ce37421003140316s30530ac0gd4a43f00b3cec00b@mail.gmail.com>
Message-ID: <20100314161830.A23D13A4062@sparrow.telecommunity.com>

At 09:16 PM 3/14/2010 +1100, Nicholas Bower wrote:
>I have the following simple dependencies using setuptools;
>
>       install_requires=['shapely==1.0.14','sqlalchemy==0.5.8'],
>
>Two questions;
>
>1) Shapely will not work.  The available packages are;
>
>Shapely-1.0.14.win32.py24.exe (md5).
>Shapely-1.0.14.win32.py25.exe (md5).
>Shapely-1.0.14.win32.py26.exe (md5).
>
>but python version is not being appended as below.  Is shapely thus
>incompatible with setuptools?

No; the problem is that there's a broken link on the Shapely home 
page at http://trac.gispython.org/lab/wiki/Shapely - it links to a 
non-existent .exe file in this line:

"Windows users should use the executable 
<http://pypi.python.org/packages/2.5/S/Shapely/Shapely-1.0.14.win32.exe#md5=92281555b23623b8cf7b4fbc9d01f17a> 
installer, which contains the required GEOS DLL"

easy_install is seeing this link and thinks it's preferable, due to 
the way it sorts candidate URLs, and it isn't smart enough (yet) to 
backtrack on broken links.

You can work around this by adding 'dependency_links=[]' to your 
setup(), replacing the [] with a list of specific links to the 
individual .exe files; this will keep easy_install from ever reading 
the PyPI page or wiki page with the broken link.

Of course, you should also suggest the shapely maintainers fix the 
broken link, since it is broken for humans as well as for easy_install.  ;-)


>2) How does one say "the latest release of sqlalchemy 0.5.x".
>Unfortunately <0.6 picks up 0.6beta and I can see no way to do
>wildcards in the docs and just say "give me the latest 0.5 series".

<0.6dev will do the trick.


From nick at petangent.net  Sun Mar 14 22:49:24 2010
From: nick at petangent.net (Nick Bower)
Date: Mon, 15 Mar 2010 08:49:24 +1100
Subject: [Distutils] setuptools dependencies failure and wildcards
In-Reply-To: <20100314161830.A23D13A4062@sparrow.telecommunity.com>
References: <59ce37421003140316s30530ac0gd4a43f00b3cec00b@mail.gmail.com>
	<20100314161830.A23D13A4062@sparrow.telecommunity.com>
Message-ID: <C899B25F-8EE7-4533-92C6-2F5ACF4C55F4@petangent.net>

Thanks but why would easy install go to pypi, ignore the obvious  
download urls and proceed to an external wiki to text search for a (as  
you point out broken) URL. Ie why not satisfy the dependency from the  
pypi page alone?

Clearly I'm new to setup tools so if this is answered elsewhere  
appologies.

On 15/03/2010, at 3:18 AM, "P.J. Eby" <pje at telecommunity.com> wrote:

> At 09:16 PM 3/14/2010 +1100, Nicholas Bower wrote:
>> I have the following simple dependencies using setuptools;
>>
>>      install_requires=['shapely==1.0.14','sqlalchemy==0.5.8'],
>>
>> Two questions;
>>
>> 1) Shapely will not work.  The available packages are;
>>
>> Shapely-1.0.14.win32.py24.exe (md5).
>> Shapely-1.0.14.win32.py25.exe (md5).
>> Shapely-1.0.14.win32.py26.exe (md5).
>>
>> but python version is not being appended as below.  Is shapely thus
>> incompatible with setuptools?
>
> No; the problem is that there's a broken link on the Shapely home  
> page at http://trac.gispython.org/lab/wiki/Shapely - it links to a  
> non-existent .exe file in this line:
>
> "Windows users should use the executable <http://pypi.python.org/packages/2.5/S/Shapely/Shapely-1.0.14.win32.exe#md5=92281555b23623b8cf7b4fbc9d01f17a 
> > installer, which contains the required GEOS DLL"
>
> easy_install is seeing this link and thinks it's preferable, due to  
> the way it sorts candidate URLs, and it isn't smart enough (yet) to  
> backtrack on broken links.
>
> You can work around this by adding 'dependency_links=[]' to your  
> setup(), replacing the [] with a list of specific links to the  
> individual .exe files; this will keep easy_install from ever reading  
> the PyPI page or wiki page with the broken link.
>
> Of course, you should also suggest the shapely maintainers fix the  
> broken link, since it is broken for humans as well as for  
> easy_install.  ;-)
>
>
>> 2) How does one say "the latest release of sqlalchemy 0.5.x".
>> Unfortunately <0.6 picks up 0.6beta and I can see no way to do
>> wildcards in the docs and just say "give me the latest 0.5 series".
>
> <0.6dev will do the trick.
>

From pje at telecommunity.com  Mon Mar 15 02:09:05 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 14 Mar 2010 21:09:05 -0400
Subject: [Distutils] setuptools dependencies failure and wildcards
In-Reply-To: <C899B25F-8EE7-4533-92C6-2F5ACF4C55F4@petangent.net>
References: <59ce37421003140316s30530ac0gd4a43f00b3cec00b@mail.gmail.com>
	<20100314161830.A23D13A4062@sparrow.telecommunity.com>
	<C899B25F-8EE7-4533-92C6-2F5ACF4C55F4@petangent.net>
Message-ID: <20100315010909.31D673A4062@sparrow.telecommunity.com>

At 08:49 AM 3/15/2010 +1100, Nick Bower wrote:
>Thanks but why would easy install go to pypi, ignore the obvious
>download urls

It doesn't ignore them; it loads them, along with any found on "home 
page" or "download" links from there.  It just doesn't choose one to 
use until it's seen all of them, in order to make sure it gets the 
best match, rather than just the first match.

>and proceed to an external wiki to text search for a (as
>you point out broken) URL. Ie why not satisfy the dependency from the
>pypi page alone?

As I said below, it has to do with the sort order for URLs that are 
otherwise equally usable:

>On 15/03/2010, at 3:18 AM, "P.J. Eby" <pje at telecommunity.com> wrote:
>>easy_install is seeing this link and thinks it's preferable, due to
>>the way it sorts candidate URLs, and it isn't smart enough (yet) to
>>backtrack on broken links.


From mbaiju at zeomega.com  Mon Mar 15 09:41:42 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Mon, 15 Mar 2010 14:11:42 +0530
Subject: [Distutils] use of '_' in package name causing version parsing
	issue?
In-Reply-To: <1099b90b1003121208t2d8bc45aj29af6f3640b0f0e5@mail.gmail.com>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<1099b90b1003121208t2d8bc45aj29af6f3640b0f0e5@mail.gmail.com>
Message-ID: <c911c70d1003150141t540fe076pd1e5db9f9afaf8db@mail.gmail.com>

Hi Jim,

On Sat, Mar 13, 2010 at 1:38 AM, Jim Fulton <jim at zope.com> wrote:
> On Tue, Mar 9, 2010 at 4:03 PM, Brad Allen <bradallen137 at gmail.com> wrote:
>> Today I was informed of an issue in which buildout (with the latest
>> setuptools) is not resolving version numbers properly, causing the
>> wrong package to be selected in some cases. The cause identified was
>> having '_' in the package name. I am still investigating this issue,
>> but thought it would be worth mentioning on the list in case anyone
>> had a quick answer.
>>
>> Here is the note I received which raised the issue:
>
> Sorry, I didn't realize that this thread was about buildout.
>
> Brad, could you send me a simple buildout.cfg (ideally one that
> installs one project) that illustrates the problem and I'll dig into
> it.

I have created a branch to demonstrate the issue:

svn+ssh://baijum at svn.zope.org/repos/main/zc.buildout/branches/baijum-project-name-with-underscore

Please look at this test file: src/zc/buildout/project_name_issue.txt

http://svn.zope.org/repos/main/zc.buildout/branches/baijum-project-name-with-underscore/src/zc/buildout/project_name_issue.txt

When I run the test cases like this, I am getting error:

$ ./bin/test -t project_name_issue
Running zope.testing.testrunner.layer.UnitTests tests:
  Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.


Failure in test /mnt/a9/wa/zc.buildout/src/zc/buildout/project_name_issue.txt
Failed doctest test for project_name_issue.txt
  File "/mnt/a9/wa/zc.buildout/src/zc/buildout/project_name_issue.txt", line 0

----------------------------------------------------------------------
File "/mnt/a9/wa/zc.buildout/src/zc/buildout/project_name_issue.txt",
line 45, in project_name_issue.txt
Failed example:
    print system(buildout),
Expected:
    Getting distribution for 'foo-bar'.
    Got foo-bar 1.
    Installing foo_bar.
    recipe v1
Got:
    Getting distribution for 'foo-bar'.
    Got foo-bar 1.
    While:
      Installing.
      Getting section foo_bar.
      Initializing section foo_bar.
      Installing recipe foo_bar.
      Getting distribution for 'foo-bar'.
    Error: Picked: foo-bar = V.V

  Ran 4 tests with 1 failures and 0 errors in 0.720 seconds.
Tearing down left over layers:
  Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.

Regards,
Baiju M

From mbaiju at zeomega.com  Mon Mar 15 10:28:45 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Mon, 15 Mar 2010 14:58:45 +0530
Subject: [Distutils] use of '_' in package name causing version parsing
	issue?
In-Reply-To: <c911c70d1003150141t540fe076pd1e5db9f9afaf8db@mail.gmail.com>
References: <4957f1ef1003091303p427900b7l25c5f7d29a5ee5ae@mail.gmail.com>
	<1099b90b1003121208t2d8bc45aj29af6f3640b0f0e5@mail.gmail.com>
	<c911c70d1003150141t540fe076pd1e5db9f9afaf8db@mail.gmail.com>
Message-ID: <c911c70d1003150228q5d166729gd75a49e9e9aa90bc@mail.gmail.com>

On Mon, Mar 15, 2010 at 2:11 PM, Baiju M <mbaiju at zeomega.com> wrote:
> Hi Jim,
>
> On Sat, Mar 13, 2010 at 1:38 AM, Jim Fulton <jim at zope.com> wrote:
>> On Tue, Mar 9, 2010 at 4:03 PM, Brad Allen <bradallen137 at gmail.com> wrote:
>>> Today I was informed of an issue in which buildout (with the latest
>>> setuptools) is not resolving version numbers properly, causing the
>>> wrong package to be selected in some cases. The cause identified was
>>> having '_' in the package name. I am still investigating this issue,
>>> but thought it would be worth mentioning on the list in case anyone
>>> had a quick answer.
>>>
>>> Here is the note I received which raised the issue:
>>
>> Sorry, I didn't realize that this thread was about buildout.
>>
>> Brad, could you send me a simple buildout.cfg (ideally one that
>> installs one project) that illustrates the problem and I'll dig into
>> it.
>
> I have created a branch to demonstrate the issue:
>
> svn+ssh://baijum at svn.zope.org/repos/main/zc.buildout/branches/baijum-project-name-with-underscore
>
> Please look at this test file: src/zc/buildout/project_name_issue.txt
>
> http://svn.zope.org/repos/main/zc.buildout/branches/baijum-project-name-with-underscore/src/zc/buildout/project_name_issue.txt
>
> When I run the test cases like this, I am getting error:
>
> $ ./bin/test -t project_name_issue
> Running zope.testing.testrunner.layer.UnitTests tests:
> ?Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
>
>
> Failure in test /mnt/a9/wa/zc.buildout/src/zc/buildout/project_name_issue.txt
> Failed doctest test for project_name_issue.txt
> ?File "/mnt/a9/wa/zc.buildout/src/zc/buildout/project_name_issue.txt", line 0
>
> ----------------------------------------------------------------------
> File "/mnt/a9/wa/zc.buildout/src/zc/buildout/project_name_issue.txt",
> line 45, in project_name_issue.txt
> Failed example:
> ? ?print system(buildout),
> Expected:
> ? ?Getting distribution for 'foo-bar'.
> ? ?Got foo-bar 1.
> ? ?Installing foo_bar.
> ? ?recipe v1
> Got:
> ? ?Getting distribution for 'foo-bar'.
> ? ?Got foo-bar 1.
> ? ?While:
> ? ? ?Installing.
> ? ? ?Getting section foo_bar.
> ? ? ?Initializing section foo_bar.
> ? ? ?Installing recipe foo_bar.
> ? ? ?Getting distribution for 'foo-bar'.
> ? ?Error: Picked: foo-bar = V.V
>
> ?Ran 4 tests with 1 failures and 0 errors in 0.720 seconds.
> Tearing down left over layers:
> ?Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.

I tried this patch and the test is passing:

Index: src/zc/buildout/buildout.py
===================================================================
--- src/zc/buildout/buildout.py (revision 109967)
+++ src/zc/buildout/buildout.py (working copy)
@@ -265,7 +265,10 @@

         versions = options.get('versions')
         if versions:
-            zc.buildout.easy_install.default_versions(dict(self[versions]))
+            safe_versions = {}
+            for package, version in self[versions].items():
+                safe_versions[pkg_resources.safe_name(package)] = version
+            zc.buildout.easy_install.default_versions(safe_versions)

         prefer_final = options.get('prefer-final', 'false')
         if prefer_final not in ('true', 'false'):


--
Baiju M

From sridharr at activestate.com  Mon Mar 15 19:18:51 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 15 Mar 2010 11:18:51 -0700
Subject: [Distutils] distribute_setup.use_setuptools: what if I want to keep
	the existing old setuptools?
Message-ID: <E3250B14-EED8-4F26-8DED-9A1EB2D06A92@activestate.com>

Tarek,

For some background on this, see http://bitbucket.org/srid/modern-package-template/issue/9/distribute_setup-should-not-be-used#comment-139503

The intent behind calling distribute_setup.use_setuptools (and ez_setup.use_setuptools) is that if the user does not have setuptools installed,  running "python setup.py install" will automatically install it for him. 

But if the user already has setuptools, running distribute_setup.use_setuptools upgrades that installation to Distribute. This goes against the original intention, correct?

Is it reasonable to provide an option to `use_setuptools` that would decide if Distribute must replace the existing setuptools or not?

-srid



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100315/71bd374f/attachment.html>

From sridharr at activestate.com  Mon Mar 15 23:27:26 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 15 Mar 2010 15:27:26 -0700
Subject: [Distutils] distribute_setup.use_setuptools: what if I want to
	keep the existing old setuptools?
In-Reply-To: <E3250B14-EED8-4F26-8DED-9A1EB2D06A92@activestate.com>
References: <E3250B14-EED8-4F26-8DED-9A1EB2D06A92@activestate.com>
Message-ID: <DB22BF91-8491-41E4-9CDF-A477B7FA24F6@activestate.com>

I just noticed that the part recommending distribute_setup.py is removed from the guide:

  http://bitbucket.org/tarek/hitchhiker-guide-packaging/changeset/1aab7be7c4be/

It originally read as:

"""
Packages built and distributed using ``setuptools`` (provided by :ref:`distribute_info`) look to the user like ordinary Python packages based on the :mod:`distutils` module. Your users don?t need to install or even know about ``setuptools`` in order to use them,  and you don?t have to include the entire ``setuptools`` package in your distributions. By including the `distribute_setup.py <http://python-distribute.org/distribute_setup.py>`_,  which is a single bootstrap module (an 8K .py file),  your package will automatically download and install ``setuptools`` if the user is building your package from source and doesn't have a suitable version already installed
"""

This gives me further confidence about the below-stated intent behind using distribute_setup.use_setuptools. But the question is: should it replace setuptools with Distribute? I'd say not. There should at least be an option (as suggested below) to accept setuptools if it is found, and install distribute only if neither setuptools nor distribute is already installed.

-srid

On 2010-03-15, at 11:18 AM, Sridhar Ratnakumar wrote:

> Tarek,
> 
> For some background on this, see http://bitbucket.org/srid/modern-package-template/issue/9/distribute_setup-should-not-be-used#comment-139503
> 
> The intent behind calling distribute_setup.use_setuptools (and ez_setup.use_setuptools) is that if the user does not have setuptools installed,  running "python setup.py install" will automatically install it for him. 
> 
> But if the user already has setuptools, running distribute_setup.use_setuptools upgrades that installation to Distribute. This goes against the original intention, correct?
> 
> Is it reasonable to provide an option to `use_setuptools` that would decide if Distribute must replace the existing setuptools or not?
> 
> -srid
> 
> 
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100315/dbf330a4/attachment.html>

From chris at simplistix.co.uk  Tue Mar 16 09:26:27 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 16 Mar 2010 08:26:27 +0000
Subject: [Distutils] repeatable and updatable virtualenv
Message-ID: <4B9F40B3.90401@simplistix.co.uk>

Hi All,

How can I set up a virtualenv in such a way that I can version control 
the packages and their versions that are installed in it?

The answer would appear to a custom bootstrap script, but how would I 
think update an existing virtualenv when I added or removed packages or 
changed the version of a specific package?

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Tue Mar 16 09:29:46 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 16 Mar 2010 08:29:46 +0000
Subject: [Distutils] setuptools dependencies failure and wildcards
In-Reply-To: <20100315010909.31D673A4062@sparrow.telecommunity.com>
References: <59ce37421003140316s30530ac0gd4a43f00b3cec00b@mail.gmail.com>	<20100314161830.A23D13A4062@sparrow.telecommunity.com>	<C899B25F-8EE7-4533-92C6-2F5ACF4C55F4@petangent.net>
	<20100315010909.31D673A4062@sparrow.telecommunity.com>
Message-ID: <4B9F417A.5080506@simplistix.co.uk>

P.J. Eby wrote:
> As I said below, it has to do with the sort order for URLs that are 
> otherwise equally usable:

Does easy_install have a way to prevent spidering off anywhere other 
than PyPI?

I know buildout has this feature, even though it is implemented rather 
loudly, but I don't know if it's implemented in buildout or inherited 
from setuptools...

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Tue Mar 16 14:35:00 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 16 Mar 2010 13:35:00 +0000
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4B9F80E6.8000406@oddbird.net>
References: <4B9F40B3.90401@simplistix.co.uk> <4B9F80E6.8000406@oddbird.net>
Message-ID: <4B9F8904.2090506@simplistix.co.uk>

Carl Meyer wrote:
> 
> Chris Withers wrote:
>> How can I set up a virtualenv in such a way that I can version control
>> the packages and their versions that are installed in it?
> 
> You'd use pip together with virtualenv (which is easy because every
> virtualenv nowadays comes with pip pre-installed), and you'd
> version-control a requirements file containing package names and versions.

Okay, but I think you said at pycon that pip won't work with binary or 
.egg distributions?

Does it play nicely with multiple indexes, some of which may be private 
and require http authentication?

> If all the package names in your requirements.txt are version-pinned,
> then "$VENV/bin/pip install -r requirements.txt" will ensure that you
> have those versions of all those packages installed. The only thing it
> won't do for you is remove packages that are no longer in
> requirements.txt; you'd need to do that yourself with "pip uninstall
> packagename" - not that having extra packages installed matters, generally.

Well, it can matter if you accidentally end up relying on them...

> Alternatively, if you want to be paranoid and you don't mind things
> being a little slower (though not much if you have a local
> PIP_DOWNLOAD_CACHE), you just create a new virtualenv each time you
> deploy. 

That won't necessarily fly... where would you put data files? outside 
the virtualenv? feels a bit weird to me, but that may just be a 
hysterical raisin...

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From carl at oddbird.net  Tue Mar 16 14:00:22 2010
From: carl at oddbird.net (Carl Meyer)
Date: Tue, 16 Mar 2010 09:00:22 -0400
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4B9F40B3.90401@simplistix.co.uk>
References: <4B9F40B3.90401@simplistix.co.uk>
Message-ID: <4B9F80E6.8000406@oddbird.net>



Chris Withers wrote:
> How can I set up a virtualenv in such a way that I can version control
> the packages and their versions that are installed in it?

You'd use pip together with virtualenv (which is easy because every
virtualenv nowadays comes with pip pre-installed), and you'd
version-control a requirements file containing package names and versions.

> The answer would appear to a custom bootstrap script, but how would I
> think update an existing virtualenv when I added or removed packages or
> changed the version of a specific package?

If all the package names in your requirements.txt are version-pinned,
then "$VENV/bin/pip install -r requirements.txt" will ensure that you
have those versions of all those packages installed. The only thing it
won't do for you is remove packages that are no longer in
requirements.txt; you'd need to do that yourself with "pip uninstall
packagename" - not that having extra packages installed matters, generally.

Alternatively, if you want to be paranoid and you don't mind things
being a little slower (though not much if you have a local
PIP_DOWNLOAD_CACHE), you just create a new virtualenv each time you
deploy. Virtualenvs are disposable, only the requirements.txt matters.

Carl

From yonsy at aureal.com.pe  Tue Mar 16 14:42:11 2010
From: yonsy at aureal.com.pe (Yonsy Solis)
Date: Tue, 16 Mar 2010 08:42:11 -0500
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4B9F40B3.90401@simplistix.co.uk>
References: <4B9F40B3.90401@simplistix.co.uk>
Message-ID: <1268746931.29119.5.camel@jenna>

On Tue, 2010-03-16 at 08:26 +0000, Chris Withers wrote:

> Hi All,
> 
> How can I set up a virtualenv in such a way that I can version control 
> the packages and their versions that are installed in it?
> 
> The answer would appear to a custom bootstrap script, but how would I 
> think update an existing virtualenv when I added or removed packages or 
> changed the version of a specific package?

we use a virtualenv bootstrap script that set an virtualenv+buildout
project, using the same directory as base for both ones, we dont find
any problems with this setup in our projects.

then we only set the versions for the packages that we like in the
buildout recipe. another advantage is that any command installed in the
bin/ dir for the buildout can be called directly if we activate the
virtualenv.

our script if find an bootstrap.py and buildout.cfg files in the same
dir that we run the virtualenv bootstrap script, build the system, ideal
for deployments in production

--
Yonsy Solis
Aureal Systems
(mov) 989-124-141
(www) http://www.aureal.pe



From pje at telecommunity.com  Tue Mar 16 15:28:56 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 16 Mar 2010 10:28:56 -0400
Subject: [Distutils] setuptools dependencies failure and wildcards
In-Reply-To: <4B9F417A.5080506@simplistix.co.uk>
References: <59ce37421003140316s30530ac0gd4a43f00b3cec00b@mail.gmail.com>
	<20100314161830.A23D13A4062@sparrow.telecommunity.com>
	<C899B25F-8EE7-4533-92C6-2F5ACF4C55F4@petangent.net>
	<20100315010909.31D673A4062@sparrow.telecommunity.com>
	<4B9F417A.5080506@simplistix.co.uk>
Message-ID: <20100316142849.E9F833A4097@sparrow.telecommunity.com>

At 08:29 AM 3/16/2010 +0000, Chris Withers wrote:
>P.J. Eby wrote:
>>As I said below, it has to do with the sort order for URLs that are 
>>otherwise equally usable:
>
>Does easy_install have a way to prevent spidering off anywhere other 
>than PyPI?

--allow-hosts=pypi.python.org would probably do it.


From carl at oddbird.net  Tue Mar 16 16:23:30 2010
From: carl at oddbird.net (Carl Meyer)
Date: Tue, 16 Mar 2010 11:23:30 -0400
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4B9F8904.2090506@simplistix.co.uk>
References: <4B9F40B3.90401@simplistix.co.uk> <4B9F80E6.8000406@oddbird.net>
	<4B9F8904.2090506@simplistix.co.uk>
Message-ID: <4B9FA272.1060707@oddbird.net>



Chris Withers wrote:
> Okay, but I think you said at pycon that pip won't work with binary or
> .egg distributions?

True; IIUC the plan is to eventually support some form of binary package
for Windows, but currently binary packages are not supported at all. I
don't have the need for binary packages; if I did I imagine my first
step would involve version-controlling a simple shell script using
easy_install or something. Or if that became unwieldy I'd look to a
buildout-based solution?

> Does it play nicely with multiple indexes, some of which may be private
> and require http authentication?

Multiple indexes, sure; you can replace PyPI or layer an additional
index on top of it, or just use --find-links with a directory. HTTP auth
I don't believe is supported, though I'm not completely sure; wouldn't
be hard to add, pip just uses urllib2.

>> Alternatively, if you want to be paranoid and you don't mind things
>> being a little slower (though not much if you have a local
>> PIP_DOWNLOAD_CACHE), you just create a new virtualenv each time you
>> deploy. 
> 
> That won't necessarily fly... where would you put data files? outside
> the virtualenv? feels a bit weird to me, but that may just be a
> hysterical raisin...

Nothing goes inside my virtualenvs except code installed via pip. The
virtualenv is a deployment artifact, not a folder container for my
project. My project code checkout, any data files, anything I care about
goes in its own location outside the virtualenv. I'm sure that does seem
odd coming from a buildout background, but AFAICS there's no good reason
to ever manually touch files inside the virtualenv directory, and lots
of good reasons not to.

Carl

From john at industromatic.com  Tue Mar 16 20:18:36 2010
From: john at industromatic.com (John Griessen)
Date: Tue, 16 Mar 2010 14:18:36 -0500
Subject: [Distutils] mr.developer questions
Message-ID: <4B9FD98C.1020003@industromatic.com>

I made a buildout including mr.developer, changed some of my django app files
such as urls.py, reran buildout and changes gone, so I misunderstood.

What is the VCS underlying mr.developer, SVN?, and how to you tell it to
add files and commit via mr.developer?

John

From m.van.rees at zestsoftware.nl  Wed Mar 17 00:00:08 2010
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Wed, 17 Mar 2010 00:00:08 +0100
Subject: [Distutils] mr.developer questions
In-Reply-To: <4B9FD98C.1020003@industromatic.com>
References: <4B9FD98C.1020003@industromatic.com>
Message-ID: <hnp2hp$jks$1@dough.gmane.org>

Op 16-03-10 20:18, John Griessen schreef:
> I made a buildout including mr.developer, changed some of my django app
> files
> such as urls.py, reran buildout and changes gone, so I misunderstood.

Anything in the 'parts' directory is fair game for being removed and 
recreated when buildout is running and it thinks this part needs 
updating.  Perhaps this tripped you up?

> What is the VCS underlying mr.developer, SVN?, and how to you tell it to
> add files and commit via mr.developer?

mr.developer can handle svn, mercurial, git and cvs. I don't see bazaar 
in the list; maybe you are using that?

I remember seeing some reports about problems with git support (usually 
quickly fixed by Florian Schulze) and the recent 1.11 release was 
followed a day later by a release fixing svn checkouts.  So you may want 
to see if the version you are using is the latest.  See 
http://pypi.python.org/pypi/mr.developer#changelog

Adding files or committing is not something that mr.developer does.  So 
in the case of svn you just go to for example src/your.package and you 
do an 'svn commit' from there.

-- 
Maurits van Rees


From suno.ano at sunoano.org  Wed Mar 17 08:22:35 2010
From: suno.ano at sunoano.org (Suno Ano)
Date: Wed, 17 Mar 2010 08:22:35 +0100
Subject: [Distutils] repeatable and updatable virtualenv
References: <4B9F40B3.90401@simplistix.co.uk>
Message-ID: <87y6hrcszo.fsf@wks.lan>

 Chris> Hi All, How can I set up a virtualenv in such a way that I can
 Chris> version control the packages and their versions that are
 Chris> installed in it?

requirements.txt and pip has already been mentioned. If you need to
version control particular packages, you might use pip install -e and
install them directly from e.g. Git/SVN/...


From chris at simplistix.co.uk  Wed Mar 17 08:35:53 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 17 Mar 2010 07:35:53 +0000
Subject: [Distutils] setuptools dependencies failure and wildcards
In-Reply-To: <20100316142849.E9F833A4097@sparrow.telecommunity.com>
References: <59ce37421003140316s30530ac0gd4a43f00b3cec00b@mail.gmail.com>
	<20100314161830.A23D13A4062@sparrow.telecommunity.com>
	<C899B25F-8EE7-4533-92C6-2F5ACF4C55F4@petangent.net>
	<20100315010909.31D673A4062@sparrow.telecommunity.com>
	<4B9F417A.5080506@simplistix.co.uk>
	<20100316142849.E9F833A4097@sparrow.telecommunity.com>
Message-ID: <4BA08659.1040307@simplistix.co.uk>

P.J. Eby wrote:
> At 08:29 AM 3/16/2010 +0000, Chris Withers wrote:
>> P.J. Eby wrote:
>>> As I said below, it has to do with the sort order for URLs that are 
>>> otherwise equally usable:
>>
>> Does easy_install have a way to prevent spidering off anywhere other 
>> than PyPI?
> 
> --allow-hosts=pypi.python.org would probably do it.

Yep, thanks.

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Wed Mar 17 10:35:02 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 17 Mar 2010 09:35:02 +0000
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4B9FA272.1060707@oddbird.net>
References: <4B9F40B3.90401@simplistix.co.uk> <4B9F80E6.8000406@oddbird.net>
	<4B9F8904.2090506@simplistix.co.uk> <4B9FA272.1060707@oddbird.net>
Message-ID: <4BA0A246.9030406@simplistix.co.uk>

Carl Meyer wrote:
> 
> Chris Withers wrote:
>> Okay, but I think you said at pycon that pip won't work with binary or
>> .egg distributions?
> 
> True; IIUC the plan is to eventually support some form of binary package
> for Windows, but currently binary packages are not supported at all.

This is, quite frankly, ridiculous, and not just because of Windows.
So, say I produce a binary egg for mysqldb, pip's position appears to be 
that I'm wrong, and I should have to make sure all the build 
dependencies are present on my whole cluster of identical machines.
Same goes for lxml, and anything else with complex build dependencies.
Really, wtf? ;-)

> don't have the need for binary packages; if I did I imagine my first
> step would involve version-controlling a simple shell script using
> easy_install or something. Or if that became unwieldy I'd look to a
> buildout-based solution?

Right, so I guess I'm back to buildout...

>> Does it play nicely with multiple indexes, some of which may be private
>> and require http authentication?
> 
> Multiple indexes, sure; you can replace PyPI or layer an additional
> index on top of it, or just use --find-links with a directory. HTTP auth
> I don't believe is supported, though I'm not completely sure; wouldn't
> be hard to add, pip just uses urllib2.

Hmm, but it's not there yes, and it is with buildout...

> Nothing goes inside my virtualenvs except code installed via pip. The
> virtualenv is a deployment artifact, not a folder container for my
> project. My project code checkout, any data files, anything I care about
> goes in its own location outside the virtualenv. I'm sure that does seem
> odd coming from a buildout background, but AFAICS there's no good reason
> to ever manually touch files inside the virtualenv directory, and lots
> of good reasons not to.

Yeah, I think this is just a style thing :-)

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Wed Mar 17 10:39:48 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 17 Mar 2010 09:39:48 +0000
Subject: [Distutils] [buildout] selectively excluding site-packages
Message-ID: <4BA0A364.8040500@simplistix.co.uk>

Hi Guys,

I guess this is mainly aimed at Jim and Gary...

How's the work to allow control over which packages come from 
site-packages and whether or not site-packages is considered by default?

Anything I can do to help with this?

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From nick at petangent.net  Wed Mar 17 11:16:19 2010
From: nick at petangent.net (Nicholas Bower)
Date: Wed, 17 Mar 2010 21:16:19 +1100
Subject: [Distutils] disutils2 and python 2.4
Message-ID: <59ce37421003170316l7e78a280tdc01656d251bec5f@mail.gmail.com>

I joined the list after this discussion:

http://mail.python.org/pipermail/distutils-sig/2010-March/015607.html

and want to point out that even the most recent versions of Zope 2.x for
example still recommend Python 2.4.

http://www.zope.org/Products/Zope/2.11.4/Zope-2-11-4-released

In other words, there are probably alot of web apps out there (eg think
about sites on Plone CMS) potentially running Python 2.4.  I run a dedicated
Python 2.4 just for Plone for example (the buildout of which is based on
virtualenv and setuptools anyway I guess).

Whether distutils2 would be used by these projects of course is another
matter.  Just pointing out Python 2.4 is absolutely not unimportant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100317/a4a8335d/attachment.html>

From m.van.rees at zestsoftware.nl  Wed Mar 17 11:42:05 2010
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Wed, 17 Mar 2010 11:42:05 +0100
Subject: [Distutils] disutils2 and python 2.4
In-Reply-To: <59ce37421003170316l7e78a280tdc01656d251bec5f@mail.gmail.com>
References: <59ce37421003170316l7e78a280tdc01656d251bec5f@mail.gmail.com>
Message-ID: <hnqblt$3mm$1@dough.gmane.org>

Op 17-03-10 11:16, Nicholas Bower schreef:
> I joined the list after this discussion:
>
> http://mail.python.org/pipermail/distutils-sig/2010-March/015607.html
>
> and want to point out that even the most recent versions of Zope 2.x for
> example still recommend Python 2.4.
>
> http://www.zope.org/Products/Zope/2.11.4/Zope-2-11-4-released

Except that at the top of http://www.zope.org/Products/Zope you will see 
that as of version 2.12 releases are made to the Python Package Index, 
at http://pypi.python.org/pypi/Zope2

To quote one of the changelog entries there: "Officially supporting 
Python 2.6 only (with inofficial support for Python 2.5) but dropping 
any support and responsibility for Python 2.4."

Note that the front of the www.zope.org now points to 
http://zope2.zope.org/ as a better source of information for Zope 2.

> In other words, there are probably alot of web apps out there (eg think
> about sites on Plone CMS) potentially running Python 2.4.  I run a
> dedicated Python 2.4 just for Plone for example (the buildout of which
> is based on virtualenv and setuptools anyway I guess).
>
> Whether distutils2 would be used by these projects of course is another
> matter.  Just pointing out Python 2.4 is absolutely not unimportant.

Agreed, I am in the Plone business and daily use Plone 3, which needs 
Zope 2.10, which needs Python 2.4.  The upcoming Plone 4 (first beta 
available) will use Zope 2.12, so will use Python 2.6, which is a good 
thing.

-- 
Maurits van Rees


From gary.poster at canonical.com  Wed Mar 17 15:00:52 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Wed, 17 Mar 2010 10:00:52 -0400
Subject: [Distutils] [buildout] selectively excluding site-packages
In-Reply-To: <4BA0A364.8040500@simplistix.co.uk>
References: <4BA0A364.8040500@simplistix.co.uk>
Message-ID: <9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>


On Mar 17, 2010, at 5:39 AM, Chris Withers wrote:

> Hi Guys,
> 
> I guess this is mainly aimed at Jim and Gary...
> 
> How's the work to allow control over which packages come from site-packages and whether or not site-packages is considered by default?

Jim asked if I tested all branches with all pertinent Python versions.  After almost two weeks, I replied "no."  Only the branches that I considered deploying internally were tested in that way.  I haven't heard if Jim wants me to make all branches pass that way, but I offered.

> Anything I can do to help with this?

From my perspective, sure.  Use the most recent branch and report problems.  I'm sure there will be some.  I need to make bootstrap more defensive, for instance.  Maybe I'll have time for that today.

bzr branch is lp:~gary/zc.buildout/python-support-8-support-subprocess and svn is http://svn.zope.org/repos/main/zc.buildout/branches/gary-8/ .

Gary

From john at industromatic.com  Wed Mar 17 16:39:43 2010
From: john at industromatic.com (John Griessen)
Date: Wed, 17 Mar 2010 10:39:43 -0500
Subject: [Distutils] [buildout]  pythonpath
Message-ID: <4BA0F7BF.3000602@industromatic.com>

I've got a buildout config partially working, but missing
ability to find some views.

How would you add paths to find

cottagematic_bld/cottagematic_com/polls
and /home/john/djangotemplates

to this buildout config?

---------------------------------
[buildout]
eggs-directory = /home/john/buildout/eggs
extensions = mr.developer
sources = sources
auto-checkout = django-mptt

parts =
     django

eggs =
     mock
     django-notification
     django-page-cms
     django-haystack

[sources]
django-mptt = svn http://django-mptt.googlecode.com/svn/trunk/ rev=>0.2.2 path=src-untouched

[django]
recipe = djangorecipe
version = 1.1.1
settings = development
urls =
     http://code.google.com/p/django-messages/source/browse/#svn/branches/messages-0.4.x

wsgi = true
eggs = ${buildout:eggs}
project = cottagematic_com
-------------------------------------------------

The django app has info to find things, but somehow the python path
doesn't get all of it.  From django settings.py:

INSTALLED_APPS = (
     'django.contrib.auth',
     'django.contrib.contenttypes',
     'django.contrib.sessions',
     'django.contrib.admin',
)

TEMPLATE_LOADERS = (
     'django.template.loaders.filesystem.load_template_source',
     'django.template.loaders.app_directories.load_template_source',
)

TEMPLATE_DIRS = (
     os.path.join(os.path.dirname(__file__), "templates"),
     "/home/john/djangotemplates"



thanks,

John

From reinout at vanrees.org  Wed Mar 17 17:06:50 2010
From: reinout at vanrees.org (Reinout van Rees)
Date: Wed, 17 Mar 2010 17:06:50 +0100
Subject: [Distutils] [buildout]  pythonpath
In-Reply-To: <4BA0F7BF.3000602@industromatic.com>
References: <4BA0F7BF.3000602@industromatic.com>
Message-ID: <hnqump$hap$1@dough.gmane.org>

On 03/17/2010 04:39 PM, John Griessen wrote:
> I've got a buildout config partially working, but missing
> ability to find some views.
>
> How would you add paths to find
>
> cottagematic_bld/cottagematic_com/polls
> and /home/john/djangotemplates
>
> to this buildout config?
>
> ---------------------------------
> [buildout]
> eggs-directory = /home/john/buildout/eggs
> extensions = mr.developer
> sources = sources
> auto-checkout = django-mptt
>
> parts =
> django
>
> eggs =
> mock
> django-notification
> django-page-cms
> django-haystack
>
> [sources]
> django-mptt = svn http://django-mptt.googlecode.com/svn/trunk/
> rev=>0.2.2 path=src-untouched
>
> [django]
> recipe = djangorecipe
> version = 1.1.1
> settings = development
> urls =
> http://code.google.com/p/django-messages/source/browse/#svn/branches/messages-0.4.x

Ehm, I don't know that urls parameter? The url points at some django app 
in svn.  If you want to install that one via svn you could look at 
http://pypi.python.org/pypi/infrae.subversion to install it (and then 
add it to your eggs list).

Not sure I'm looking in the right direction here as your usecase isn't 
completely clear to me.

> The django app has info to find things, but somehow the python path
> doesn't get all of it. From django settings.py:

First things first: check your bin/django file to see if you miss things 
from the PYTHON path side of things.  If that's the full list you 
expect, then you can look further in the django settings.

> INSTALLED_APPS = (
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.admin',
> )

Apps that aren't listed here aren't searched for templates: is this the 
full list?  You might want to add your "site project" here, too.

> TEMPLATE_LOADERS = (
> 'django.template.loaders.filesystem.load_template_source',
> 'django.template.loaders.app_directories.load_template_source',
> )

I'm missing the egg loader template source that's here by default. 
Perhaps that one helps?


Reinout


-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Programmer at http://www.nelen-schuurmans.nl
"Military engineers build missiles. Civil engineers build targets"


From john at industromatic.com  Wed Mar 17 18:15:03 2010
From: john at industromatic.com (John Griessen)
Date: Wed, 17 Mar 2010 12:15:03 -0500
Subject: [Distutils] [buildout]  pythonpath
In-Reply-To: <hnqump$hap$1@dough.gmane.org>
References: <4BA0F7BF.3000602@industromatic.com> <hnqump$hap$1@dough.gmane.org>
Message-ID: <4BA10E17.7090407@industromatic.com>

Reinout van Rees wrote:
> On 03/17/2010 04:39 PM, John Griessen wrote:
>> I've got a buildout config partially working, but missing
>> ability to find some views.
>
> First things first: check your bin/django file to see if you miss things 
> from the PYTHON path side of things.  If that's the full list you 
> expect, then you can look further in the django settings.
> 
>> INSTALLED_APPS = (
>> 'django.contrib.auth',
>> 'django.contrib.contenttypes',
>> 'django.contrib.sessions',
>> 'django.contrib.admin',
>> )
> 
> Apps that aren't listed here aren't searched for templates: is this the 
> full list?  You might want to add your "site project" here, too.
> 


>> TEMPLATE_LOADERS = (
>> 'django.template.loaders.filesystem.load_template_source',
>> 'django.template.loaders.app_directories.load_template_source',
>> )
> 
> I'm missing the egg loader template source that's here by default. 
> Perhaps that one helps?
> 
> 
> Reinout
> 
> 

My bin/django file does not have a path to admin templates


--------------------
#!/usr/bin/python

import sys
sys.path[0:0] = [
   '/home/john/buildout/eggs/mock-0.6.0-py2.5.egg',
   '/home/john/buildout/eggs/django_notification-0.1.5-py2.5.egg',
   '/home/john/buildout/eggs/django_page_cms-1.1.2-py2.5.egg',
   '/home/john/buildout/eggs/django_haystack-1.0.1_final-py2.5.egg',
   '/home/john/buildout/eggs/djangorecipe-0.20-py2.5.egg',
   '/home/john/buildout/eggs/zc.recipe.egg-1.2.2-py2.5.egg',
   '/home/john/buildout/eggs/zc.buildout-1.4.3-py2.5.egg',
   '/home/john/buildout/eggs/django_staticfiles-0.2.0-py2.5.egg',
   '/home/john/buildout/eggs/django_authority-0.4-py2.5.egg',
   '/home/john/WEBprojects/cottagematic_bld/src-untouched/django-mptt',
   '/home/john/buildout/eggs/django_tagging-0.3.1-py2.5.egg',
   '/home/john/buildout/eggs/html5lib-0.90-py2.5.egg',
   '/home/john/WEBprojects/cottagematic_bld/parts/django',
   '/home/john/buildout/eggs/BeautifulSoup-3.1.0.1-py2.5.egg',
   '/usr/lib/python2.5/site-packages',
   '/home/john/WEBprojects/cottagematic_bld/parts/django',
   '/home/john/WEBprojects/cottagematic_bld',
   ]

import djangorecipe.manage

if __name__ == '__main__':
     djangorecipe.manage.main('cottagematic_com.development')
------------------------------------

the pythonpath when error happens has

cottagematic_bld/parts/django'
cottagematic_bld/src-untouched/django-mptt'
cottagematic_bld
cottagematic_bld/bin

I think it needs cottagematic_bld/cottagematic_com
the project directory.



From ktenney at gmail.com  Wed Mar 17 18:33:31 2010
From: ktenney at gmail.com (Kent Tenney)
Date: Wed, 17 Mar 2010 12:33:31 -0500
Subject: [Distutils] buildout / distribute issue
Message-ID: <ca816811003171033k6260935emd301333fea4a652d@mail.gmail.com>

I'm abusing buildout thusly:

$ mkdir bo
$ cd bo
$ wget http://python-distribute.org/bootstrap.py

buildout.cfg:
----------------------------
[buildout]
parts = interp

[interp]
recipe = zc.recipe.egg
interpreter = py
eggs =
----------------------------

$ python bootstrap.py -d
$ bin/buildout

Installing interp.
Installing .
Generated interpreter '/tmp/bo/bin/py'.

$ bin/py

  File "bin/py", line 6
    ,
    ^
SyntaxError: invalid syntax

from bin/py:
-----------------------------------
sys.path[0:0] = [
  ,
  ]
-----------------------------------

Thanks,
Kent

From pje at telecommunity.com  Wed Mar 17 18:59:17 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 17 Mar 2010 13:59:17 -0400
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4BA0A246.9030406@simplistix.co.uk>
References: <4B9F40B3.90401@simplistix.co.uk> <4B9F80E6.8000406@oddbird.net>
	<4B9F8904.2090506@simplistix.co.uk> <4B9FA272.1060707@oddbird.net>
	<4BA0A246.9030406@simplistix.co.uk>
Message-ID: <20100317175913.185383A4097@sparrow.telecommunity.com>

At 09:35 AM 3/17/2010 +0000, Chris Withers wrote:
>Carl Meyer wrote:
>>Chris Withers wrote:
>>>Okay, but I think you said at pycon that pip won't work with binary or
>>>.egg distributions?
>>True; IIUC the plan is to eventually support some form of binary package
>>for Windows, but currently binary packages are not supported at all.
>
>This is, quite frankly, ridiculous, and not just because of Windows.
>So, say I produce a binary egg for mysqldb, pip's position appears 
>to be that I'm wrong, and I should have to make sure all the build 
>dependencies are present on my whole cluster of identical machines.
>Same goes for lxml, and anything else with complex build dependencies.
>Really, wtf? ;-)

Ian might not be here to say it, but if he were, I imagine he might 
say, "patches welcome".  ;-)

Seriously, though, I've posted samples here more than once of the 
basic code needed to extract an .egg into a pip-style configuration, 
and easy_install has code that will turn windows .exe files into .egg 
files.  Those parts aren't hard at all, relatively speaking.

What somebody would still need to write, are the pip-specific bits to 
wrap all that in an installation process (including finding the 
downloadables in the first place).


From jim at zope.com  Wed Mar 17 19:00:54 2010
From: jim at zope.com (Jim Fulton)
Date: Wed, 17 Mar 2010 14:00:54 -0400
Subject: [Distutils] buildout / distribute issue
In-Reply-To: <ca816811003171033k6260935emd301333fea4a652d@mail.gmail.com>
References: <ca816811003171033k6260935emd301333fea4a652d@mail.gmail.com>
Message-ID: <1099b90b1003171100q284702a8wfe047718be98abad@mail.gmail.com>

On Wed, Mar 17, 2010 at 1:33 PM, Kent Tenney <ktenney at gmail.com> wrote:
> I'm abusing buildout thusly:
>
> $ mkdir bo
> $ cd bo
> $ wget http://python-distribute.org/bootstrap.py
>
> buildout.cfg:
> ----------------------------
> [buildout]
> parts = interp
>
> [interp]
> recipe = zc.recipe.egg
> interpreter = py
> eggs =
> ----------------------------
>
> $ python bootstrap.py -d
> $ bin/buildout
>
> Installing interp.
> Installing .
> Generated interpreter '/tmp/bo/bin/py'.
>
> $ bin/py
>
> ?File "bin/py", line 6
> ? ?,
> ? ?^
> SyntaxError: invalid syntax
>
> from bin/py:
> -----------------------------------
> sys.path[0:0] = [
> ?,
> ?]
> -----------------------------------

This looks like a buildout bug. Please report it at

  https://bugs.launchpad.net/zc.buildout/+filebug

Jim

-- 
Jim Fulton

From reinout at vanrees.org  Thu Mar 18 10:11:49 2010
From: reinout at vanrees.org (Reinout van Rees)
Date: Thu, 18 Mar 2010 10:11:49 +0100
Subject: [Distutils] [buildout]  pythonpath
In-Reply-To: <4BA10E17.7090407@industromatic.com>
References: <4BA0F7BF.3000602@industromatic.com> <hnqump$hap$1@dough.gmane.org>
	<4BA10E17.7090407@industromatic.com>
Message-ID: <hnsqol$e1h$1@dough.gmane.org>

On 03/17/2010 06:15 PM, John Griessen wrote:
>
> My bin/django file does not have a path to admin templates

The paths in bin/django are locations where python looks for *python 
code*.  So "from django.conf import settings" or so means "search on 
sys.path for django.conf", basically.

The sys.path in bin/django has nothing to do with template locations, 
apart from one thing: all your django apps need to be findable here for 
the template loader to be able to find templates in there.

I see django in that list, so that's OK:

> #!/usr/bin/python
>
> import sys
> sys.path[0:0] = [
> '/home/john/buildout/eggs/mock-0.6.0-py2.5.egg',
 > [...snip...]
> '/home/john/WEBprojects/cottagematic_bld/parts/django',

Bingo, parts/django.

And you've got django.contrib.auth in your INSTALLED_APPS list, so 
that's OK, too.

Weird.

Some further brainstorming:

- You're missing "cottagematic_com" (your project) in the INSTALLED_APPS 
list.  Is that right?

- Your sys.path contains '/usr/lib/python2.5/site-packages', which is 
not something buildout puts in there by default.  Did you modify it by hand?

- Your parts/django comes *after* (and also before) that suspicious 
site-packages: do you perhaps have a different django version installed 
globally that is thus found earlier than the django you want?

- Your cottagematic_bld similarly: that's after site-packages, so you 
might not be using the settings.py of that 
'/home/john/WEBprojects/cottagematic_bld', but of an older/different 
version if that's by chance installed globally in that site-packages.

Hm. Probably a good idea to remove the bin/ directory and re-run buildout.


Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Programmer at http://www.nelen-schuurmans.nl
"Military engineers build missiles. Civil engineers build targets"


From barthelemy at crans.org  Thu Mar 18 15:05:44 2010
From: barthelemy at crans.org (=?ISO-8859-1?Q?S=E9bastien_Barth=E9lemy?=)
Date: Thu, 18 Mar 2010 15:05:44 +0100
Subject: [Distutils] distutils: upload fails if maintainer name is unicode
Message-ID: <78f7ab621003180705n428709c0y1d94ef8b76edd57a@mail.gmail.com>

Hello,

when I run "python setup.py sdist upload" on my package, it fails with
the following traceback:

Traceback (most recent call last):
  File "setup.py", line 86, in <module>
    cmdclass=cmdclass)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/core.py",
line 152, in setup
    dist.run_commands()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/dist.py",
line 987, in run_commands
    self.run_command(cmd)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/dist.py",
line 1007, in run_command
    cmd_obj.run()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/command/upload.py",
line 57, in run
    self.upload_file(command, pyversion, filename)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/command/upload.py",
line 135, in upload_file
    value = str(value)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
position 1: ordinal not in range(128)

I'm running Python 2.6.4 on mac os X. Note also that I could register
the package on pypi without any problem.

Apparently, the problem occurs because of the
maintainer=u'S?bastien BARTH?LEMY' argument to the setup command.

This seems to be a known problem :
 http://bugs.python.org/issue1076233
 http://stackoverflow.com/questions/1162338/whats-the-right-way-to-use-unicode-metadata-in-setup-py

If I read well, it should be fixed in 2.6. Can you confirm this
problem is (at least officially) fixed for python 2.6.4 ? Any idea or
workaround ?

Thanks

S?bastien

From ziade.tarek at gmail.com  Thu Mar 18 15:30:48 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 18 Mar 2010 10:30:48 -0400
Subject: [Distutils] distutils: upload fails if maintainer name is
	unicode
In-Reply-To: <78f7ab621003180705n428709c0y1d94ef8b76edd57a@mail.gmail.com>
References: <78f7ab621003180705n428709c0y1d94ef8b76edd57a@mail.gmail.com>
Message-ID: <94bdd2611003180730q2fb41a5erbacb0b66558db5e@mail.gmail.com>

HI S?bastien,

2010/3/18 S?bastien Barth?lemy <barthelemy at crans.org>:
[..]
>
> If I read well, it should be fixed in 2.6. Can you confirm this
> problem is (at least officially) fixed for python 2.6.4 ? Any idea or
> workaround ?

This bug was fixed for the register command some time ago, and I've
fixed the upload command recently (r77719), so you can expect 2.6.5 to
behave correctly for that matter.

(2.6.5 is coming out very soon)

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Thu Mar 18 15:41:09 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 18 Mar 2010 10:41:09 -0400
Subject: [Distutils] disutils2 and python 2.4
In-Reply-To: <59ce37421003170316l7e78a280tdc01656d251bec5f@mail.gmail.com>
References: <59ce37421003170316l7e78a280tdc01656d251bec5f@mail.gmail.com>
Message-ID: <94bdd2611003180741o6de56ee4hda1ba4849c4b4052@mail.gmail.com>

On Wed, Mar 17, 2010 at 6:16 AM, Nicholas Bower <nick at petangent.net> wrote:
> I joined the list after this discussion:
> http://mail.python.org/pipermail/distutils-sig/2010-March/015607.html
> and want to point out that even the most recent versions of Zope 2.x for
> example still recommend Python 2.4.
[..]
>?Just pointing out Python 2.4 is absolutely not unimportant.

Agreed, we are targetting 2.4 in any case, its used by many people
(see the rest of the thread)

Regards
Tarek


-- 
Tarek Ziad? | http://ziade.org

From alain.leufroy at logilab.fr  Thu Mar 18 15:47:06 2010
From: alain.leufroy at logilab.fr (Alain Leufroy)
Date: Thu, 18 Mar 2010 15:47:06 +0100
Subject: [Distutils] setuptools data_files and bdist_egg
Message-ID: <201003181547.06164.alain.leufroy@logilab.fr>

I'm a setuptools user and I appreciate it a lot, particularly for the 
automatic dependency installation and eggs.
I found over the web that one of egg features is that files shouldn't be 
strewn all over the disk. However is there a way to put files outside the egg 
install directory (e.g. /usr/share/doc) ?

The data_file list given as an argument to the setup method allows to specify 
where data files should be installed. But when I try to install a 
distribution using easy_install with an .egg file, all data files are copied 
in the egg install directory. This means that the prefix for relative path 
specified in the data_file list is the egg install directory instead of 
<sys.prefix>.
Is there a way to force easy_install to use <sys.prefix> as the prefix for 
relative data file paths ?

Best regards
-- 
Alain Leufroy

From barthelemy at crans.org  Thu Mar 18 15:48:35 2010
From: barthelemy at crans.org (=?ISO-8859-1?Q?S=E9bastien_Barth=E9lemy?=)
Date: Thu, 18 Mar 2010 15:48:35 +0100
Subject: [Distutils] distutils: upload fails if maintainer name is
	unicode
In-Reply-To: <94bdd2611003180730q2fb41a5erbacb0b66558db5e@mail.gmail.com>
References: <78f7ab621003180705n428709c0y1d94ef8b76edd57a@mail.gmail.com>
	<94bdd2611003180730q2fb41a5erbacb0b66558db5e@mail.gmail.com>
Message-ID: <78f7ab621003180748k7af2420dlbb4d5dfb0b1c0829@mail.gmail.com>

Hello Tarek,

thank you for the fast reply.
I guess I'll just wait.

Regards

From ziade.tarek at gmail.com  Thu Mar 18 15:52:11 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 18 Mar 2010 10:52:11 -0400
Subject: [Distutils] distutils: upload fails if maintainer name is
	unicode
In-Reply-To: <78f7ab621003180748k7af2420dlbb4d5dfb0b1c0829@mail.gmail.com>
References: <78f7ab621003180705n428709c0y1d94ef8b76edd57a@mail.gmail.com>
	<94bdd2611003180730q2fb41a5erbacb0b66558db5e@mail.gmail.com>
	<78f7ab621003180748k7af2420dlbb4d5dfb0b1c0829@mail.gmail.com>
Message-ID: <94bdd2611003180752g30c78996r8b592be250a292a0@mail.gmail.com>

On Thu, Mar 18, 2010 at 10:48 AM, S?bastien Barth?lemy
<barthelemy at crans.org> wrote:
> Hello Tarek,
>
> thank you for the fast reply.
> I guess I'll just wait.

If you need it today, and you control your python installation, the
patch is quite simple to do
(one liner)

let me know if you want it,

>
> Regards
>



-- 
Tarek Ziad? | http://ziade.org

From pje at telecommunity.com  Thu Mar 18 16:09:44 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 18 Mar 2010 11:09:44 -0400
Subject: [Distutils] setuptools data_files and bdist_egg
In-Reply-To: <201003181547.06164.alain.leufroy@logilab.fr>
References: <201003181547.06164.alain.leufroy@logilab.fr>
Message-ID: <20100318150941.81F343A4125@sparrow.telecommunity.com>

At 03:47 PM 3/18/2010 +0100, Alain Leufroy wrote:
>Is there a way to force easy_install to use <sys.prefix> as the prefix for
>relative data file paths ?

You can use easy_install -e to download and unpack the source for the 
thing you want to install, then use "setup.py install 
--single-version-externally-managed".  This will not use the .egg 
installation format, and thus allows things to be installed to places 
other than a single lib dir and bin dir.

Alternatively, you could perhaps use pip, which automates a process 
very similar to that.  (I'm not sure if it really supports this or 
not, but you could read the docs or try it out.) 


From saintger at gmail.com  Thu Mar 18 19:05:14 2010
From: saintger at gmail.com (Saint Germain)
Date: Thu, 18 Mar 2010 19:05:14 +0100
Subject: [Distutils] [buildout] Impossible to install develop eggs
Message-ID: <5e5cdb041003181105s5ff5ef72r6bfd81afc21f489c@mail.gmail.com>

Hello,

I'm trying to use buildout with develop eggs, but it seems that they cannot
be installed.

Here is the scenario :

1)
I create a simple project in /home/user/project
mkdir mymodule
touch mymodule/__init__.py
echo -e "from setuptools import setup\nPACKAGE = 'mymodule'\nVERSION =
'0.1'\nsetup(name=PACKAGE, version=VERSION, packages=['mymodule'] )" >
setup.py

2) I use the following buildout.cfg
[buildout]
develop = /home/af79141/project
parts = eggs

[eggs]
recipe = zc.recipe.egg
eggs = mymodule

3) I copy bootstrap.py in the directory (
http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py)

4) python bootstrap.py

5) bin/buildout

I end up with the following content:
bin
bootstrap.py
buildout.cfg
develop-eggs
eggs
parts

No lib/python/site-packages are created !
But there is a file mymodule.egg-link in develop-eggs with the following
content:
/home/users/project
.
What am I doing wrong ?
I was expecting a created file like lib/python/site-packages/mymodule ?

Thanks in advance,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100318/600ce529/attachment-0001.html>

From marrakis at gmail.com  Thu Mar 18 19:13:19 2010
From: marrakis at gmail.com (Mathieu Leduc-Hamel)
Date: Thu, 18 Mar 2010 14:13:19 -0400
Subject: [Distutils] [buildout] Impossible to install develop eggs
In-Reply-To: <5e5cdb041003181105s5ff5ef72r6bfd81afc21f489c@mail.gmail.com>
References: <5e5cdb041003181105s5ff5ef72r6bfd81afc21f489c@mail.gmail.com>
Message-ID: <c2c16f991003181113g46b521b1xb3c9ff3ec60de20e@mail.gmail.com>

No you're not right here. With buildout, when you are using the
develop clause, it create a link in the develop-eggs dir and if look
inside the new file it would point to your package directory directly.

After that you can install the egg in the "eggs' section and use it
directly as it would be installed from pypi.

is it working correctly ?

On Thu, Mar 18, 2010 at 2:05 PM, Saint Germain <saintger at gmail.com> wrote:
> Hello,
>
> I'm trying to use buildout with develop eggs, but it seems that they cannot
> be installed.
>
> Here is the scenario :
>
> 1)
> I create a simple project in /home/user/project
> mkdir mymodule
> touch mymodule/__init__.py
> echo -e "from setuptools import setup\nPACKAGE = 'mymodule'\nVERSION =
> '0.1'\nsetup(name=PACKAGE, version=VERSION, packages=['mymodule'] )" >
> setup.py
>
> 2) I use the following buildout.cfg
> [buildout]
> develop = /home/af79141/project
> parts = eggs
>
> [eggs]
> recipe = zc.recipe.egg
> eggs = mymodule
>
> 3) I copy bootstrap.py in the directory
> (http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py)
>
> 4) python bootstrap.py
>
> 5) bin/buildout
>
> I end up with the following content:
> bin
> bootstrap.py
> buildout.cfg
> develop-eggs
> eggs
> parts
>
> No lib/python/site-packages are created !
> But there is a file mymodule.egg-link in develop-eggs with the following
> content:
> /home/users/project
> .
> What am I doing wrong ?
> I was expecting a created file like lib/python/site-packages/mymodule ?
>
> Thanks in advance,
>
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>

From jim at zope.com  Thu Mar 18 20:23:10 2010
From: jim at zope.com (Jim Fulton)
Date: Thu, 18 Mar 2010 15:23:10 -0400
Subject: [Distutils] [buildout] Impossible to install develop eggs
In-Reply-To: <5e5cdb041003181105s5ff5ef72r6bfd81afc21f489c@mail.gmail.com>
References: <5e5cdb041003181105s5ff5ef72r6bfd81afc21f489c@mail.gmail.com>
Message-ID: <1099b90b1003181223n54092356uc85044711113686d@mail.gmail.com>

On Thu, Mar 18, 2010 at 2:05 PM, Saint Germain <saintger at gmail.com> wrote:
> Hello,
>
> I'm trying to use buildout with develop eggs, but it seems that they cannot
> be installed.
>
> Here is the scenario :
>
> 1)
> I create a simple project in /home/user/project
> mkdir mymodule
> touch mymodule/__init__.py
> echo -e "from setuptools import setup\nPACKAGE = 'mymodule'\nVERSION =
> '0.1'\nsetup(name=PACKAGE, version=VERSION, packages=['mymodule'] )" >
> setup.py
>
> 2) I use the following buildout.cfg
> [buildout]
> develop = /home/af79141/project
> parts = eggs
>
> [eggs]
> recipe = zc.recipe.egg
> eggs = mymodule
>
> 3) I copy bootstrap.py in the directory
> (http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py)
>
> 4) python bootstrap.py
>
> 5) bin/buildout
>
> I end up with the following content:
> bin
> bootstrap.py
> buildout.cfg
> develop-eggs
> eggs
> parts
>
> No lib/python/site-packages are created !

Nor should they.  When you use develop eggs, they are added to the
develop-eggs directory.


> But there is a file mymodule.egg-link in develop-eggs with the following
> content:
> /home/users/project

Yup, that's what you should get.


> .
> What am I doing wrong ?

I don't know, what are you trying to do?

Jim

-- 
Jim Fulton

From saintger at gmail.com  Thu Mar 18 23:38:25 2010
From: saintger at gmail.com (Saint Germain)
Date: Thu, 18 Mar 2010 23:38:25 +0100
Subject: [Distutils] [buildout] Impossible to install develop eggs
In-Reply-To: <1099b90b1003181223n54092356uc85044711113686d@mail.gmail.com>
References: <5e5cdb041003181105s5ff5ef72r6bfd81afc21f489c@mail.gmail.com>
	<1099b90b1003181223n54092356uc85044711113686d@mail.gmail.com>
Message-ID: <20100318233825.6d50ee73@debian>

On Thu, 18 Mar 2010 15:23:10 -0400, Jim Fulton <jim at zope.com> wrote :


> > I'm trying to use buildout with develop eggs, but it seems that
> > they cannot be installed.
> >
> > I end up with the following content:
> > bin
> > bootstrap.py
> > buildout.cfg
> > develop-eggs
> > eggs
> > parts
> >
> > No lib/python/site-packages are created !
> 
> Nor should they.  When you use develop eggs, they are added to the
> develop-eggs directory.
> 

Yes I understand that, but I wanted to install those eggs to a regular
directory after.

> > But there is a file mymodule.egg-link in develop-eggs with the
> > following content:
> > /home/users/project
> 
> Yup, that's what you should get.
> 
> 
> > .
> > What am I doing wrong ?
> 
> I don't know, what are you trying to do?
> 

The idea is to have a link between
lib/python/site-packages/mymodule.egg-link
and /home/user/project/mymodule. That way I can't both have a
representative installed environment (using "import mymodule" works in
this environment) and the ability to continue developing on my regular
personal directory.

What is the point to have the develop eggs in the develop-eggs if I'm
not able to use them ?

I was under the impression that I needed to install those eggs:
http://www.k4ml.com/node/271

Using pip, if I install a development environment, I end up exactly
with that file (content is the same):
lib/python/site-packages/mymodule.egg-link

I hope that I was clear on my intent.
Don't hesitate if it's not the case !

Regards,

From saintger at gmail.com  Thu Mar 18 23:42:53 2010
From: saintger at gmail.com (Saint Germain)
Date: Thu, 18 Mar 2010 23:42:53 +0100
Subject: [Distutils] [buildout] Impossible to install develop eggs
In-Reply-To: <c2c16f991003181113g46b521b1xb3c9ff3ec60de20e@mail.gmail.com>
References: <5e5cdb041003181105s5ff5ef72r6bfd81afc21f489c@mail.gmail.com>
	<c2c16f991003181113g46b521b1xb3c9ff3ec60de20e@mail.gmail.com>
Message-ID: <20100318234253.063ef866@debian>

On Thu, 18 Mar 2010 14:13:19 -0400, Mathieu Leduc-Hamel
<marrakis at gmail.com> wrote :

> No you're not right here. With buildout, when you are using the
> develop clause, it create a link in the develop-eggs dir and if look
> inside the new file it would point to your package directory directly.
> 
> After that you can install the egg in the "eggs' section and use it
> directly as it would be installed from pypi.
> 
> is it working correctly ?
> 

Hello,

I understand what is the meaning of the develop clause and that I
should end up with the mymodule.egg-link in the develop-eggs directory

Problem is only that I don't manage to install this egg.
In the buildout.cfg, I tried to install it but nothing happen (no error
message, nothing).

I was expecting that:
1) the buildout.cfg I gave would trigger the installation of
this egg
2) After installation of this egg, I would have mymodule.egg-link in
the site-packages directory.

But it seems that it's not at all the expected behavior ?

Regards,

From chris at simplistix.co.uk  Fri Mar 19 11:27:21 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 19 Mar 2010 10:27:21 +0000
Subject: [Distutils] [buildout] selectively excluding site-packages
In-Reply-To: <9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>
References: <4BA0A364.8040500@simplistix.co.uk>
	<9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>
Message-ID: <4BA35189.8050401@simplistix.co.uk>

Gary Poster wrote:
> On Mar 17, 2010, at 5:39 AM, Chris Withers wrote:
> 
>> Hi Guys,
>>
>> I guess this is mainly aimed at Jim and Gary...
>>
>> How's the work to allow control over which packages come from site-packages and whether or not site-packages is considered by default?
> 
> Jim asked if I tested all branches with all pertinent Python versions.  After almost two weeks, I replied "no."  Only the branches that I considered deploying internally were tested in that way.  I haven't heard if Jim wants me to make all branches pass that way, but I offered.

Ah, I thought you'd rolled all the branches up into one uber-branch?

> From my perspective, sure.  Use the most recent branch and report problems.  I'm sure there will be some.  I need to make bootstrap more defensive, for instance.  Maybe I'll have time for that today.
> 
> bzr branch is lp:~gary/zc.buildout/python-support-8-support-subprocess and svn is http://svn.zope.org/repos/main/zc.buildout/branches/gary-8/ .

Okay, I'll see what I can do...

Are these any docs on the new features on that branch? If so, where 
should I look?

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Fri Mar 19 11:29:50 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 19 Mar 2010 10:29:50 +0000
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <20100317175913.185383A4097@sparrow.telecommunity.com>
References: <4B9F40B3.90401@simplistix.co.uk> <4B9F80E6.8000406@oddbird.net>
	<4B9F8904.2090506@simplistix.co.uk> <4B9FA272.1060707@oddbird.net>
	<4BA0A246.9030406@simplistix.co.uk>
	<20100317175913.185383A4097@sparrow.telecommunity.com>
Message-ID: <4BA3521E.3050605@simplistix.co.uk>

P.J. Eby wrote:
> At 09:35 AM 3/17/2010 +0000, Chris Withers wrote:
>> Carl Meyer wrote:
>>> Chris Withers wrote:
>>>> Okay, but I think you said at pycon that pip won't work with binary or
>>>> .egg distributions?
>>> True; IIUC the plan is to eventually support some form of binary package
>>> for Windows, but currently binary packages are not supported at all.
>>
>> This is, quite frankly, ridiculous, and not just because of Windows.
>> So, say I produce a binary egg for mysqldb, pip's position appears to 
>> be that I'm wrong, and I should have to make sure all the build 
>> dependencies are present on my whole cluster of identical machines.
>> Same goes for lxml, and anything else with complex build dependencies.
>> Really, wtf? ;-)
> 
> Ian might not be here to say it, but if he were, I imagine he might say, 
> "patches welcome".  ;-)

It's likely easier for me to get buildout to do what I need, which is a 
shame, since I *do* like the feel of virtualenv...

> Seriously, though, I've posted samples here more than once of the basic 
> code needed to extract an .egg into a pip-style configuration,

I'm not following you, I don't want to extract any eggs, I just want to 
have dependencies satisfied by distributions that may well be binary eggs.

> What somebody would still need to write, are the pip-specific bits to 
> wrap all that in an installation process (including finding the 
> downloadables in the first place).

I thought pip just used setuptools/easyinstall for that anyway?

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From bradallen137 at gmail.com  Fri Mar 19 14:31:09 2010
From: bradallen137 at gmail.com (Brad Allen)
Date: Fri, 19 Mar 2010 07:31:09 -0600
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4B9F40B3.90401@simplistix.co.uk>
References: <4B9F40B3.90401@simplistix.co.uk>
Message-ID: <4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>

On Tue, Mar 16, 2010 at 2:26 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> Hi All,
>
> How can I set up a virtualenv in such a way that I can version control the
> packages and their versions that are installed in it?
>
> The answer would appear to a custom bootstrap script, but how would I think
> update an existing virtualenv when I added or removed packages or changed
> the version of a specific package?


You could try envbuilder; I find it very helpful for setting up
development environments repeatably when developing several related
packages ('er, 'module distributions') simultaneously.

It basically just creates a virtualenv, checks out/clones whatever you
specify in the .env confiig file, and runs setup.py develop on each of
the checked out packages into the virtualenv. Also, it provides a way
to apply commands across all the checked out packages (like 'update'
or 'status')

http://pypi.python.org/pypi/envbuilder/0.1.4

I think a similar functionality can be had using buildout with
mr.developer, but I have not tried it yet. However as far as I know,
buildout does not create a virtualenv (yet).

From saintger at gmail.com  Fri Mar 19 16:24:45 2010
From: saintger at gmail.com (Saint Germain)
Date: Fri, 19 Mar 2010 16:24:45 +0100
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>
References: <4B9F40B3.90401@simplistix.co.uk>
	<4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>
Message-ID: <5e5cdb041003190824t47d48091s6bcf6602a3b00ca7@mail.gmail.com>

2010/3/19 Brad Allen <bradallen137 at gmail.com>
>
> On Tue, Mar 16, 2010 at 2:26 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> > Hi All,
> >
> > How can I set up a virtualenv in such a way that I can version control the
> > packages and their versions that are installed in it?
> >
> > The answer would appear to a custom bootstrap script, but how would I think
> > update an existing virtualenv when I added or removed packages or changed
> > the version of a specific package?
>
>
> You could try envbuilder; I find it very helpful for setting up
> development environments repeatably when developing several related
> packages ('er, 'module distributions') simultaneously.
>
> It basically just creates a virtualenv, checks out/clones whatever you
> specify in the .env confiig file, and runs setup.py develop on each of
> the checked out packages into the virtualenv. Also, it provides a way
> to apply commands across all the checked out packages (like 'update'
> or 'status')
>
> http://pypi.python.org/pypi/envbuilder/0.1.4
>
> I think a similar functionality can be had using buildout with
> mr.developer, but I have not tried it yet. However as far as I know,
> buildout does not create a virtualenv (yet).


I'm currently trying more or less the same thing by combining buildout
with virtualenv and pip.
So far it's working without problem except the installation of develop
eggs (see my other message).

Buildout can create virtualenv without problem (see
http://pypi.python.org/pypi/rjm.recipe.venv/0.7) and can use pip to
install editable package (see
http://pypi.python.org/pypi/gp.recipe.pip) under version control (CVS,
SVN, Mercurial...)

Now if only I can solve the develop eggs issue, I would be very happy !

From saintger at gmail.com  Fri Mar 19 16:48:59 2010
From: saintger at gmail.com (Saint Germain)
Date: Fri, 19 Mar 2010 16:48:59 +0100
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4957f1ef1003190832w316c6678l6127ff5c394387f1@mail.gmail.com>
References: <4B9F40B3.90401@simplistix.co.uk>
	<4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>
	<5e5cdb041003190823i661f18c4w4fb1998eabe21946@mail.gmail.com>
	<4957f1ef1003190832w316c6678l6127ff5c394387f1@mail.gmail.com>
Message-ID: <5e5cdb041003190848w5298fc51pf6f98be0289bf94b@mail.gmail.com>

2010/3/19 Brad Allen <bradallen137 at gmail.com>:
> On Fri, Mar 19, 2010 at 10:23 AM, Saint Germain <saintger at gmail.com> wrote:
>>
>> 2010/3/19 Brad Allen <bradallen137 at gmail.com>
>>>
>>> On Tue, Mar 16, 2010 at 2:26 AM, Chris Withers <chris at simplistix.co.uk>
>>> wrote:
>>> > Hi All,
>>> >
>>> > How can I set up a virtualenv in such a way that I can version control
>>> > the
>>> > packages and their versions that are installed in it?
>>> >
>>> > The answer would appear to a custom bootstrap script, but how would I
>>> > think
>>> > update an existing virtualenv when I added or removed packages or
>>> > changed
>>> > the version of a specific package?
>>>
>>>
>>> You could try envbuilder; I find it very helpful for setting up
>>> development environments repeatably when developing several related
>>> packages ('er, 'module distributions') simultaneously.
>>>
>>> It basically just creates a virtualenv, checks out/clones whatever you
>>> specify in the .env confiig file, and runs setup.py develop on each of
>>> the checked out packages into the virtualenv. Also, it provides a way
>>> to apply commands across all the checked out packages (like 'update'
>>> or 'status')
>>>
>>> http://pypi.python.org/pypi/envbuilder/0.1.4
>>>
>>> I think a similar functionality can be had using buildout with
>>> mr.developer, but I have not tried it yet. However as far as I know,
>>> buildout does not create a virtualenv (yet).
>>>
>>
>> I'm currently trying more or less the same thing by combining buildout with
>> virtualenv and pip.
>> So far it's working without problem except the installation of develop eggs
>> (see my other message).
>>
>> Buildout can create virtualenv without problem (see
>> http://pypi.python.org/pypi/rjm.recipe.venv/0.7) and can use pip to install
>> editable package (see http://pypi.python.org/pypi/gp.recipe.pip) under
>> version control (CVS, SVN, Mercurial...)
>
> Thanks for the tip!
>
>
>> Now if only I can solve the develop eggs issue, I would be very happy !
>
> What is that issue?
>

See here:
http://mail.python.org/pipermail/distutils-sig/2010-March/015729.html

I think that it's not a bug or a missing functionality but it's just
that I haven't fully understand the whole thing about develop eggs.
The eggs are correctly generated but I haven't managed to install them
automatically.

Anyway after it is solved, I can confirm that buildout + distribute +
virtualenv + pip is a very powerful combination !

Don't hesitate to ask questions if you want to use the same approach.
There are some points which are still rough and I need to send some
patch upstreams. But mainly it works (and rocks).

Regards,

From gary.poster at canonical.com  Fri Mar 19 16:58:06 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Fri, 19 Mar 2010 11:58:06 -0400
Subject: [Distutils] [buildout] selectively excluding site-packages
In-Reply-To: <4BA35189.8050401@simplistix.co.uk>
References: <4BA0A364.8040500@simplistix.co.uk>
	<9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>
	<4BA35189.8050401@simplistix.co.uk>
Message-ID: <5DB278AC-8CC2-4E87-A9B3-C691C90D859A@canonical.com>


On Mar 19, 2010, at 6:27 AM, Chris Withers wrote:

> Gary Poster wrote:
>> On Mar 17, 2010, at 5:39 AM, Chris Withers wrote:
>>> Hi Guys,
>>> 
>>> I guess this is mainly aimed at Jim and Gary...
>>> 
>>> How's the work to allow control over which packages come from site-packages and whether or not site-packages is considered by default?
>> Jim asked if I tested all branches with all pertinent Python versions.  After almost two weeks, I replied "no."  Only the branches that I considered deploying internally were tested in that way.  I haven't heard if Jim wants me to make all branches pass that way, but I offered.
> 
> Ah, I thought you'd rolled all the branches up into one uber-branch?

Each branch builds on the previous one, so that's pretty much true.

(I am keeping the bzr branch lp:~gary/zc.buildout/python-support up-to-date with both trunk and my branches, but that's really more of an internal artifact.)

>> From my perspective, sure.  Use the most recent branch and report problems.  I'm sure there will be some.  I need to make bootstrap more defensive, for instance.  Maybe I'll have time for that today.
>> bzr branch is lp:~gary/zc.buildout/python-support-8-support-subprocess and svn is http://svn.zope.org/repos/main/zc.buildout/branches/gary-8/ .
> 
> Okay, I'll see what I can do...
> 
> Are these any docs on the new features on that branch? If so, where should I look?

The user-visible part of the changes is in the z3c.recipe.scripts recipe contained within the zc.buildout checkout, like zc.recipe.egg.  zc.recipe.egg has no user-visible changes and works mostly as before, providing hopefully full backwards compatibility.  z3c.recipe.scripts has the logic to work with a Python that might have some site-packages hanging around.

http://svn.zope.org/zc.buildout/branches/gary-8/z3c.recipe.scripts_/src/z3c/recipe/scripts/README.txt?view=auto

Note that mixing a system python's site-packages and buildout eggs will, in my guess, always be less stable than trying to simply use a system Python without site-packages at all (the default behavior of the new recipe).  See the discussion in the README file, which touches on the concerns but probably does not go far enough.  That said, for "hysterical" reasons, I'm using the mixing approach right now myself.

Gary

From jbaker at zeomega.com  Fri Mar 19 15:19:12 2010
From: jbaker at zeomega.com (Jason Baker)
Date: Fri, 19 Mar 2010 09:19:12 -0500
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>
References: <4B9F40B3.90401@simplistix.co.uk>
	<4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>
Message-ID: <fa34f1941003190719j259b28e4h3c1ad5585f62be99@mail.gmail.com>

On Fri, Mar 19, 2010 at 8:31 AM, Brad Allen <bradallen137 at gmail.com> wrote:

> http://pypi.python.org/pypi/envbuilder/0.1.4
>
> I think a similar functionality can be had using buildout with
> mr.developer, but I have not tried it yet. However as far as I know,
> buildout does not create a virtualenv (yet).
>


For the record, the most recent stable version is 0.2.2:
http://pypi.python.org/pypi/envbuilder/0.2.2
There's also a development version in github:

Also, another option could be to use a pip requirements file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100319/792bcc82/attachment.html>

From alain.leufroy at logilab.fr  Fri Mar 19 18:08:45 2010
From: alain.leufroy at logilab.fr (Alain Leufroy)
Date: Fri, 19 Mar 2010 18:08:45 +0100
Subject: [Distutils] setuptools data_files and bdist_egg
In-Reply-To: <20100318150941.81F343A4125@sparrow.telecommunity.com>
References: <201003181547.06164.alain.leufroy@logilab.fr>
	<20100318150941.81F343A4125@sparrow.telecommunity.com>
Message-ID: <201003191808.45468.alain.leufroy@logilab.fr>

> >Is there a way to force easy_install to use <sys.prefix> as the prefix for
> >relative data file paths ?
>
> You can use easy_install -e to download and unpack the source for the
> thing you want to install, then use "setup.py install
> --single-version-externally-managed".  This will not use the .egg
> installation format, and thus allows things to be installed to places
> other than a single lib dir and bin dir.
Unfortunately this process is not convenient with dependancy which have data 
files too. 
I'm trying to build eggs in order to simplify the user install process, so 
this process is not convenient with dependancy which have data files too. 

> Alternatively, you could perhaps use pip, which automates a process
> very similar to that.  (I'm not sure if it really supports this or
> not, but you could read the docs or try it out.)
It's exactly what I've been looking for (and much more) ! 

Thanks.



-- 
Alain Leufroy
http://www.logilab.fr/
Informatique scientifique & et gestion de connaissances

From john at industromatic.com  Fri Mar 19 18:59:01 2010
From: john at industromatic.com (John Griessen)
Date: Fri, 19 Mar 2010 12:59:01 -0500
Subject: [Distutils] [buildout] selectively excluding site-packages
In-Reply-To: <5DB278AC-8CC2-4E87-A9B3-C691C90D859A@canonical.com>
References: <4BA0A364.8040500@simplistix.co.uk>	<9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>	<4BA35189.8050401@simplistix.co.uk>
	<5DB278AC-8CC2-4E87-A9B3-C691C90D859A@canonical.com>
Message-ID: <4BA3BB65.7030606@industromatic.com>

Gary Poster wrote:
>> Are these any docs on the new features on that branch? If so, where should I look?
> 
> The user-visible part of the changes is in the z3c.recipe.scripts recipe contained within the zc.buildout checkout, like
> zc.recipe.egg.  zc.recipe.egg has no user-visible changes and works mostly as before, providing hopefully full backwards
> compatibility.  z3c.recipe.scripts has the logic to work with a Python that might have some site-packages hanging around.
> 
> http://svn.zope.org/zc.buildout/branches/gary-8/z3c.recipe.scripts_/src/z3c/recipe/scripts/README.txt?view=auto
> 
> Note that mixing a system python's site-packages and buildout eggs will, in my guess, always be less stable than trying to
> simply use a system Python without site-packages at all (the default behavior of the new recipe).  See the discussion in the
> README file, which touches on the concerns but probably does not go far enough.  That said, for "hysterical" reasons, I'm using
> the mixing approach right now myself.

Suppose I'm starting fresh, (newbie at this, but wanting stability and new features).
How do you best use buildout to
"simply use a system Python without site-packages at all"?  I'm OK with reading the code for comments.

What to checkout? http://svn.zope.org/zc.buildout/branches/gary-8/z3c.recipe.scripts_
or
  http://svn.zope.org/zc.buildout/branches/gary-8  what rev?

Thanks,

John

From gary.poster at canonical.com  Fri Mar 19 19:10:51 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Fri, 19 Mar 2010 14:10:51 -0400
Subject: [Distutils] [buildout] selectively excluding site-packages
In-Reply-To: <4BA3BB65.7030606@industromatic.com>
References: <4BA0A364.8040500@simplistix.co.uk>	<9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>	<4BA35189.8050401@simplistix.co.uk>
	<5DB278AC-8CC2-4E87-A9B3-C691C90D859A@canonical.com>
	<4BA3BB65.7030606@industromatic.com>
Message-ID: <9A49BD7D-5391-41BE-A5D9-4C11471F727A@canonical.com>


On Mar 19, 2010, at 1:59 PM, John Griessen wrote:

> Gary Poster wrote:
>>> Are these any docs on the new features on that branch? If so, where should I look?
>> The user-visible part of the changes is in the z3c.recipe.scripts recipe contained within the zc.buildout checkout, like
>> zc.recipe.egg.  zc.recipe.egg has no user-visible changes and works mostly as before, providing hopefully full backwards
>> compatibility.  z3c.recipe.scripts has the logic to work with a Python that might have some site-packages hanging around.
>> http://svn.zope.org/zc.buildout/branches/gary-8/z3c.recipe.scripts_/src/z3c/recipe/scripts/README.txt?view=auto
>> Note that mixing a system python's site-packages and buildout eggs will, in my guess, always be less stable than trying to
>> simply use a system Python without site-packages at all (the default behavior of the new recipe).  See the discussion in the
>> README file, which touches on the concerns but probably does not go far enough.  That said, for "hysterical" reasons, I'm using
>> the mixing approach right now myself.
> 
> Suppose I'm starting fresh, (newbie at this, but wanting stability and new features).
> How do you best use buildout to
> "simply use a system Python without site-packages at all"?  I'm OK with reading the code for comments.

If you are a newbie, I strongly suggest sticking with the released versions.  What I have done has zero guarantee of Jim merging it.

Moreover, the instructions on how a newbie can use this stuff from source are not worth my time or yours, IMO.

I suspect those warnings are not what you want to hear, but I'm trying to be both helpful and up-front.

On the other hand, if you are asking how you *would* use a system Python if my branches were merged, you would use the new version of zc.buildout, and use z3c.recipe.scripts where you normally would have used zc.recipe.egg, except for the advanced use case of zc.recipe.egg:custom, which should still be used from zc.recipe.egg.  That's it.

Gary

From sridharr at activestate.com  Fri Mar 19 19:38:33 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Fri, 19 Mar 2010 11:38:33 -0700
Subject: [Distutils] [buildout] selectively excluding site-packages
In-Reply-To: <4BA3BB65.7030606@industromatic.com>
References: <4BA0A364.8040500@simplistix.co.uk>	<9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>	<4BA35189.8050401@simplistix.co.uk>
	<5DB278AC-8CC2-4E87-A9B3-C691C90D859A@canonical.com>
	<4BA3BB65.7030606@industromatic.com>
Message-ID: <8625AC8E-8DD7-48D5-B420-BC4C9EC8A989@activestate.com>


On 2010-03-19, at 10:59 AM, John Griessen wrote:

> How do you best use buildout to
> "simply use a system Python without site-packages at all"? 

What I do, as a workaround till buildout officially supports it, is to do this every time I run buildout:

  $ mv ..../site-packages ..../site-packages.oow
  $ bin/buildout
  $ mv ..../site-packages.oow ..../site-packages

-srid


From sridharr at activestate.com  Fri Mar 19 22:10:46 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Fri, 19 Mar 2010 14:10:46 -0700
Subject: [Distutils] How to specific metadata version in setup.py?
Message-ID: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>

My package's PKG-INFO defaults to 1.0 metadata version. I tried searching http://docs.python.org/distutils/ to know how to specify 1.2 as the metadata version (so I can include Classifiers[1], maintainer* fields in it), but couldn't find any. Does anyone know? Shouldn't this be documented in http://docs.python.org/distutils/setupscript.html which talks about these additional fields in section 2.8?

-srid

[1] Evidently, some packages in PyPI do not have 'Classifiers' in their metadata (PKG-INFO) despite specifying it in the setup.py.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100319/6cb1a063/attachment.html>

From ziade.tarek at gmail.com  Fri Mar 19 22:22:03 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 19 Mar 2010 17:22:03 -0400
Subject: [Distutils] How to specific metadata version in setup.py?
In-Reply-To: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>
References: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>
Message-ID: <94bdd2611003191422s286d669al66e17952e093506@mail.gmail.com>

On Fri, Mar 19, 2010 at 5:10 PM, Sridhar Ratnakumar
<sridharr at activestate.com> wrote:
> My package's PKG-INFO defaults to 1.0 metadata version. I tried
> searching?http://docs.python.org/distutils/?to know how to specify 1.2 as
> the metadata version (so I can include Classifiers[1], maintainer* fields in
> it), but couldn't find any. Does anyone know? Shouldn't this be documented
> in?http://docs.python.org/distutils/setupscript.html?which talks about these
> additional fields in section 2.8?
> -srid
> [1] Evidently, some packages in PyPI do not have 'Classifiers' in their
> metadata (PKG-INFO) despite specifying it in the setup.py.

You can't do it, distutils will automatically set 1.0 or 1.1 depending
on the options you have used. (and not 1.2)
IOW, if you use a PEP 314 field, the DistributionMetadata object
should switch to 1.1.

ALthough, my advice would be to use the new DistributionMetadata class
I have created in distutils2. It's a standalone, PEP 345-compatible
class you can use in your own project. It has a micro-interpreter for
the environment markers described in PEP 345, and also knows how to
read or write 1.1, 1.0 PKG-INFO files.

http://hg.python.org/distutils2/file/tip/src/distutils2/metadata.py

Feedback and contributions are welcome

Tarek


> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>



-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Fri Mar 19 22:27:03 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 19 Mar 2010 17:27:03 -0400
Subject: [Distutils] How to specific metadata version in setup.py?
In-Reply-To: <94bdd2611003191422s286d669al66e17952e093506@mail.gmail.com>
References: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>
	<94bdd2611003191422s286d669al66e17952e093506@mail.gmail.com>
Message-ID: <94bdd2611003191427y4128219es328fe0de60eef6e0@mail.gmail.com>

On Fri, Mar 19, 2010 at 5:22 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
[..]
>
> You can't do it, distutils will automatically set 1.0 or 1.1 depending
> on the options you have used. (and not 1.2)

Re-reading the current distutils (1) code, I realize that it'll switch
to 1.1 *only* if you have used
provides, requires or obsolete, so it's partially implemented.

The new class is much cleaner in the implementation, and so is the
register command for PyPI.

Notice that we have almost finished the implementation of PEP 345 on
PyPI side so we will soon be able to push PEP 345 fields over there.

Tarek

-- 
Tarek Ziad? | http://ziade.org

From sridharr at activestate.com  Fri Mar 19 22:35:48 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Fri, 19 Mar 2010 14:35:48 -0700
Subject: [Distutils] How to specific metadata version in setup.py?
In-Reply-To: <94bdd2611003191427y4128219es328fe0de60eef6e0@mail.gmail.com>
References: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>
	<94bdd2611003191422s286d669al66e17952e093506@mail.gmail.com>
	<94bdd2611003191427y4128219es328fe0de60eef6e0@mail.gmail.com>
Message-ID: <B45F021B-C8B4-4DF9-8107-3114F6EC0AE2@activestate.com>


On 2010-03-19, at 2:27 PM, Tarek Ziad? wrote:

> On Fri, Mar 19, 2010 at 5:22 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> [..]
>> 
>> You can't do it, distutils will automatically set 1.0 or 1.1 depending
>> on the options you have used. (and not 1.2)
> 
> Re-reading the current distutils (1) code, I realize that it'll switch
> to 1.1 *only* if you have used
> provides, requires or obsolete, so it's partially implemented.

Ok. As a result of this, PKG-INFO that contains the "Classifiers" fields still has 1.0 as Metadata-Version. Consequently, http://pypi.python.org/pypi/pkginfo fails to read extra metadata fields. If Tres is reading this, I had to do the following hack as a workaroud:

    from pkginfo import Distribution
    
    class PkgInfoFile(Distribution):
        # Not all packages' PKG-INFO define the proper metadata
        # For eg., modern-package-template uses the Classifiers field and yet
        # uses 1.0 as the metadata version (Classifiers is only defined in 1.1)
        metadata_version = '1.2' # not all PKG-INFO file have proper metadata version
        

> The new class is much cleaner in the implementation, and so is the
> register command for PyPI.
> 
> Notice that we have almost finished the implementation of PEP 345 on
> PyPI side so we will soon be able to push PEP 345 fields over there.

Wasn't PEP 345 fully implemented for distutils1? Ah, I see that it is still "Draft" mode. 

Can I use distutils2 to parse PKG-INFO (as a replacement for the `pkginfo` project)? Will it read all the fields despite the inaccurate Metadata-Version field?

-srid

[1] http://www.python.org/dev/peps/pep-0301/#distutils-trove-classification
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100319/f061d4eb/attachment-0001.html>

From ziade.tarek at gmail.com  Fri Mar 19 22:51:58 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 19 Mar 2010 17:51:58 -0400
Subject: [Distutils] How to specific metadata version in setup.py?
In-Reply-To: <B45F021B-C8B4-4DF9-8107-3114F6EC0AE2@activestate.com>
References: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>
	<94bdd2611003191422s286d669al66e17952e093506@mail.gmail.com>
	<94bdd2611003191427y4128219es328fe0de60eef6e0@mail.gmail.com>
	<B45F021B-C8B4-4DF9-8107-3114F6EC0AE2@activestate.com>
Message-ID: <94bdd2611003191451h1f5994ecoa6dbec0edc2f9eb2@mail.gmail.com>

On Fri, Mar 19, 2010 at 5:35 PM, Sridhar Ratnakumar
<sridharr at activestate.com> wrote:
> [..]
If Tres is reading this, I had to do the following hack as
> a workaroud:
> ?? ?from pkginfo import Distribution
>
> ?? ?class PkgInfoFile(Distribution):
> ?? ? ? ?# Not all packages' PKG-INFO define the proper metadata
> ?? ? ? ?# For eg., modern-package-template uses the Classifiers field and
> yet
> ?? ? ? ?# uses 1.0 as the metadata version (Classifiers is only defined in
> 1.1)
> ?? ? ? ?metadata_version = '1.2' # not all PKG-INFO file have proper
> metadata version

Why do you force 1.2 here ? There's no tool out there that understand
PEP 345 / 1.2 yet.
At this time, I'd encourage you to put 1.1 here unless you use PEP 345 fields.

> Wasn't PEP 345 fully implemented for distutils1? Ah, I see that it is still
> "Draft" mode.

I'll switch it to Accepted now. But PEP 345 will not be implemented in
Distutils, which is now feature frozen.

> Can I use distutils2 to parse PKG-INFO (as a replacement for the `pkginfo`
> project)?

Yes you can.

> Will it read all the fields despite the inaccurate
> Metadata-Version field?

Yes, it should work. Description fields (==long_description)
containing empty lines will stay broken though,
because they can't be read back. That's fixed in PEP 345 / 1.2

Regards
Tarek
-- 
Tarek Ziad? | http://ziade.org

From sridharr at activestate.com  Sat Mar 20 08:33:24 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Sat, 20 Mar 2010 00:33:24 -0700
Subject: [Distutils] How to specific metadata version in setup.py?
In-Reply-To: <94bdd2611003191451h1f5994ecoa6dbec0edc2f9eb2@mail.gmail.com>
References: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>
	<94bdd2611003191422s286d669al66e17952e093506@mail.gmail.com>
	<94bdd2611003191427y4128219es328fe0de60eef6e0@mail.gmail.com>
	<B45F021B-C8B4-4DF9-8107-3114F6EC0AE2@activestate.com>
	<94bdd2611003191451h1f5994ecoa6dbec0edc2f9eb2@mail.gmail.com>
Message-ID: <C60AD6F8-90B9-42AC-A54D-80BD1FF6D0AB@activestate.com>


On 2010-03-19, at 2:51 PM, Tarek Ziad? wrote:

> On Fri, Mar 19, 2010 at 5:35 PM, Sridhar Ratnakumar
> <sridharr at activestate.com> wrote:
>> [..]
> If Tres is reading this, I had to do the following hack as
>> a workaroud:
>>     from pkginfo import Distribution
>> 
>>     class PkgInfoFile(Distribution):
>>         # Not all packages' PKG-INFO define the proper metadata
>>         # For eg., modern-package-template uses the Classifiers field and
>> yet
>>         # uses 1.0 as the metadata version (Classifiers is only defined in
>> 1.1)
>>         metadata_version = '1.2' # not all PKG-INFO file have proper
>> metadata version
> 
> Why do you force 1.2 here ?

From http://pypi.python.org/pypi/pkginfo

"Added support for the different metadata versions specified in PEPs 241,  314,  and 345. Distributions now parse and expose only the attributes corresponding to their metadata version,  which defaults to the version parsed from the PKG-INFO file. The programmer can override that version when creating the distribution object."

I could as well use 1.1.

> There's no tool out there that understand
> PEP 345 / 1.2 yet.

Apparently pkginfo supports PEP 345 (see above).

> At this time, I'd encourage you to put 1.1 here unless you use PEP 345 fields.

Ok.

-srid


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100320/d3152ed5/attachment.html>

From chris at simplistix.co.uk  Fri Mar 19 21:56:54 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 19 Mar 2010 20:56:54 +0000
Subject: [Distutils] [buildout] Impossible to install develop eggs
In-Reply-To: <20100318233825.6d50ee73@debian>
References: <5e5cdb041003181105s5ff5ef72r6bfd81afc21f489c@mail.gmail.com>	<1099b90b1003181223n54092356uc85044711113686d@mail.gmail.com>
	<20100318233825.6d50ee73@debian>
Message-ID: <4BA3E516.2080408@simplistix.co.uk>

Saint Germain wrote:
>>> No lib/python/site-packages are created !
>> Nor should they.  When you use develop eggs, they are added to the
>> develop-eggs directory.
> 
> Yes I understand that, but I wanted to install those eggs to a regular
> directory after.

What do you mean "to a regular directory" and what tools do you want to 
use to do this installation?

> The idea is to have a link between
> lib/python/site-packages/mymodule.egg-link
> and /home/user/project/mymodule. That way I can't both have a
> representative installed environment (using "import mymodule" works in
> this environment) and the ability to continue developing on my regular
> personal directory.

Er, you appear to be significantly missing the point of buildout: it 
leaves site-packages well along. Nothing should go in site-packages, ever...

> What is the point to have the develop eggs in the develop-eggs if I'm
> not able to use them ?

They'll be usable within any buildout-generated script, same as 
everywhere else...

> Using pip, if I install a development environment, I end up exactly
> with that file (content is the same):
> lib/python/site-packages/mymodule.egg-link

buildout!=pip.

Buildout does its work by creating scripts which manipulate sys.path, 
virtualenv/pip do it by creating a completely new python environment.

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk


From chris at simplistix.co.uk  Fri Mar 19 22:02:16 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 19 Mar 2010 21:02:16 +0000
Subject: [Distutils] [buildout] selectively excluding site-packages
In-Reply-To: <9A49BD7D-5391-41BE-A5D9-4C11471F727A@canonical.com>
References: <4BA0A364.8040500@simplistix.co.uk>	<9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>	<4BA35189.8050401@simplistix.co.uk>	<5DB278AC-8CC2-4E87-A9B3-C691C90D859A@canonical.com>	<4BA3BB65.7030606@industromatic.com>
	<9A49BD7D-5391-41BE-A5D9-4C11471F727A@canonical.com>
Message-ID: <4BA3E658.4010708@simplistix.co.uk>

Gary Poster wrote:
> If you are a newbie, I strongly suggest sticking with the released versions.  What I have done has zero guarantee of Jim merging it.

If he doesn't, how about a fork? ;-)

> Moreover, the instructions on how a newbie can use this stuff from source are not worth my time or yours, IMO.

I'm not so sure, can't see what should prevent a new user trying all of 
this...

> On the other hand, if you are asking how you *would* use a system Python if my branches were merged, you would use the new version of zc.buildout, and use z3c.recipe.scripts where you normally would have used zc.recipe.egg,

Why is z3c.recipe.scripts required?

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk


From ziade.tarek at gmail.com  Sat Mar 20 14:39:09 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 20 Mar 2010 09:39:09 -0400
Subject: [Distutils] How to specific metadata version in setup.py?
In-Reply-To: <C60AD6F8-90B9-42AC-A54D-80BD1FF6D0AB@activestate.com>
References: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>
	<94bdd2611003191422s286d669al66e17952e093506@mail.gmail.com>
	<94bdd2611003191427y4128219es328fe0de60eef6e0@mail.gmail.com>
	<B45F021B-C8B4-4DF9-8107-3114F6EC0AE2@activestate.com>
	<94bdd2611003191451h1f5994ecoa6dbec0edc2f9eb2@mail.gmail.com>
	<C60AD6F8-90B9-42AC-A54D-80BD1FF6D0AB@activestate.com>
Message-ID: <94bdd2611003200639s2f933d0by3e48756ae4fb1a8f@mail.gmail.com>

On Sat, Mar 20, 2010 at 3:33 AM, Sridhar Ratnakumar
<sridharr at activestate.com> wrote:
[..]
>
> There's no tool out there that understand
> PEP 345 / 1.2 yet.
>
> Apparently pkginfo supports PEP 345 (see above).


It's an old version of PEP 345. It misses for example:

- Project-Url
- environment markers

I think Tres added PEP 345 support a while ago, and it needs an upgrade

Regards,
Tarek
-- 
Tarek Ziad? | http://ziade.org

From lacrima.maxim at gmail.com  Sat Mar 20 16:06:26 2010
From: lacrima.maxim at gmail.com (=?UTF-8?B?0JzQsNC60YHQuNC8IExhY3JpbWE=?=)
Date: Sat, 20 Mar 2010 17:06:26 +0200
Subject: [Distutils] [buildout] How to configure python interpreter to use
	it with Google Appengine?
Message-ID: <5bb76e241003200806j1e3bbdf2nfdb3a60a69907f94@mail.gmail.com>

Hello!

I use buildout to develop my Google Appengine application. To set up GAE I
use rod.recipe.appengine.
Thanks to this recipe I can deploy my application, use development server
etc.

Also I want my Python interpreter to access this environment, so I can
import appengine's webapp, db and so on.
I don't know how to do this.

Currently I have next configuration of the interpreter:
[python]
recipe = zc.recipe.egg:scripts
interpreter = python
eggs = myapp

With this configuration I can't access any part of google_appengine.
What should I do to properly customize Python interpreter for use with
Appengine.
Thanks in advance.

Sorry, if my English isn't proper enough.

with regards,
Maxim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100320/fde74230/attachment.html>

From tseaver at palladion.com  Sat Mar 20 17:36:07 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 20 Mar 2010 12:36:07 -0400
Subject: [Distutils] How to specific metadata version in setup.py?
In-Reply-To: <B45F021B-C8B4-4DF9-8107-3114F6EC0AE2@activestate.com>
References: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>	<94bdd2611003191422s286d669al66e17952e093506@mail.gmail.com>	<94bdd2611003191427y4128219es328fe0de60eef6e0@mail.gmail.com>
	<B45F021B-C8B4-4DF9-8107-3114F6EC0AE2@activestate.com>
Message-ID: <ho2thn$pjp$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sridhar Ratnakumar wrote:
> On 2010-03-19, at 2:27 PM, Tarek Ziad? wrote:
> 
>> On Fri, Mar 19, 2010 at 5:22 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> [..]
>>> You can't do it, distutils will automatically set 1.0 or 1.1 depending
>>> on the options you have used. (and not 1.2)
>> Re-reading the current distutils (1) code, I realize that it'll switch
>> to 1.1 *only* if you have used
>> provides, requires or obsolete, so it's partially implemented.
> 
> Ok. As a result of this, PKG-INFO that contains the "Classifiers"
> fields still has 1.0 as Metadata-Version. Consequently,
> http://pypi.python.org/pypi/pkginfo fails to read extra metadata fields.
> If Tres is reading this, I had to do the following hack as a workaroud:
> 
>     from pkginfo import Distribution
>     
>     class PkgInfoFile(Distribution):
>         # Not all packages' PKG-INFO define the proper metadata
>         # For eg., modern-package-template uses the Classifiers field and yet
>         # uses 1.0 as the metadata version (Classifiers is only defined in 1.1)
>         metadata_version = '1.2' # not all PKG-INFO file have proper metadata version

If you know you want to parse '1.2' fields regardless of the version in
the PKG-INFO file, then set the 'metadata_version' attribute on the
Distribution instance before calling 'parse'. E.g.::

  from pkginfo import Distribution
  d = Distribution()
  d.metadata_version = '1.2'
  d.parse(open('/path/to/PKG-INFO').read())

The concrete classes (SDist, BDist, Develop, Installed) all take
'metadata_version' as a constructor argument, just to provide for this
case.  I'm not sure why you would define a PkgInfo class, actually:  it
needs to have a 'read' method, at least, to allow the usual operation
('extractMetadata') to work.  I think your usecase is probably covered
by either the Installed or Develop classes.  If you do have a usedase,
the public bzr branch is here:

  lp:~tseaver/pkginfo/trunk

I'll be glad to review and merge a patch which adds your support, and
make a new release.

>> The new class is much cleaner in the implementation, and so is the
>> register command for PyPI.
>>
>> Notice that we have almost finished the implementation of PEP 345 on
>> PyPI side so we will soon be able to push PEP 345 fields over there.
> 

> Wasn't PEP 345 fully implemented for distutils1? Ah, I see that it is
> still "Draft" mode.
> 
> Can I use distutils2 to parse PKG-INFO (as a replacement for the
> `pkginfo` project)? Will it read all the fields despite the
> inaccurate Metadata-Version field?

I haven't looked at 'distutils2' yet.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEARECAAYFAkuk+XIACgkQ+gerLs4ltQ71HACfQI8VKM7jKsaQ+jyPHoY/e7vF
/jMAl0Gls9B1+kFFojjcOpRwOpFufCs=
=ZQgL
-----END PGP SIGNATURE-----


From tseaver at palladion.com  Sat Mar 20 17:39:51 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 20 Mar 2010 12:39:51 -0400
Subject: [Distutils] How to specific metadata version in setup.py?
In-Reply-To: <94bdd2611003200639s2f933d0by3e48756ae4fb1a8f@mail.gmail.com>
References: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>	<94bdd2611003191422s286d669al66e17952e093506@mail.gmail.com>	<94bdd2611003191427y4128219es328fe0de60eef6e0@mail.gmail.com>	<B45F021B-C8B4-4DF9-8107-3114F6EC0AE2@activestate.com>	<94bdd2611003191451h1f5994ecoa6dbec0edc2f9eb2@mail.gmail.com>	<C60AD6F8-90B9-42AC-A54D-80BD1FF6D0AB@activestate.com>
	<94bdd2611003200639s2f933d0by3e48756ae4fb1a8f@mail.gmail.com>
Message-ID: <ho2ton$pjp$2@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? wrote:
> On Sat, Mar 20, 2010 at 3:33 AM, Sridhar Ratnakumar
> <sridharr at activestate.com> wrote:
> [..]
>> There's no tool out there that understand
>> PEP 345 / 1.2 yet.
>>
>> Apparently pkginfo supports PEP 345 (see above).
> 
> 
> It's an old version of PEP 345. It misses for example:
> 
> - Project-Url
> - environment markers
> 
> I think Tres added PEP 345 support a while ago, and it needs an upgrade

I'm happy to take patches which add support for parsing the extra fields
and environment syntac, but given that no tools are *emitting* them yet,
I'm not likely to get around to adding them myself for a bit.

  $ bzr co lp:~tseaver/pkginfo/trunk

:)



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuk+lcACgkQ+gerLs4ltQ6HZQCdF7471zHdY26GLh01CiiTjr1+
Nu0AoMToWoWKW1Jd0nQx+YEfVdsPDhkp
=fwhE
-----END PGP SIGNATURE-----


From tseaver at palladion.com  Sat Mar 20 17:45:46 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 20 Mar 2010 12:45:46 -0400
Subject: [Distutils] [buildout] How to configure python interpreter to
 use it with Google Appengine?
In-Reply-To: <5bb76e241003200806j1e3bbdf2nfdb3a60a69907f94@mail.gmail.com>
References: <5bb76e241003200806j1e3bbdf2nfdb3a60a69907f94@mail.gmail.com>
Message-ID: <4BA4FBBA.6000201@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

?????? Lacrima wrote:
> Hello!
> 
> I use buildout to develop my Google Appengine application. To set up GAE I
> use rod.recipe.appengine.
> Thanks to this recipe I can deploy my application, use development server
> etc.
> 
> Also I want my Python interpreter to access this environment, so I can
> import appengine's webapp, db and so on.
> I don't know how to do this.
> 
> Currently I have next configuration of the interpreter:
> [python]
> recipe = zc.recipe.egg:scripts
> interpreter = python
> eggs = myapp
> 
> With this configuration I can't access any part of google_appengine.
> What should I do to properly customize Python interpreter for use with
> Appengine.
> Thanks in advance.

Can you attach the whole buildout config?

> Sorry, if my English isn't proper enough.

Your question is quite clear.  We just don't know enough about how you
are getting the GAE eggs installed here.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuk+7kACgkQ+gerLs4ltQ7uZwCcCOVDyTl1HVb1xoW1XRm70ox/
i60AoLiamazohqMnVu/SF6pf37xl52e3
=Ls81
-----END PGP SIGNATURE-----


From sridharr at activestate.com  Sat Mar 20 18:09:04 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Sat, 20 Mar 2010 10:09:04 -0700
Subject: [Distutils] How to specific metadata version in setup.py?
In-Reply-To: <94bdd2611003200639s2f933d0by3e48756ae4fb1a8f@mail.gmail.com>
References: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>
	<94bdd2611003191422s286d669al66e17952e093506@mail.gmail.com>
	<94bdd2611003191427y4128219es328fe0de60eef6e0@mail.gmail.com>
	<B45F021B-C8B4-4DF9-8107-3114F6EC0AE2@activestate.com>
	<94bdd2611003191451h1f5994ecoa6dbec0edc2f9eb2@mail.gmail.com>
	<C60AD6F8-90B9-42AC-A54D-80BD1FF6D0AB@activestate.com>
	<94bdd2611003200639s2f933d0by3e48756ae4fb1a8f@mail.gmail.com>
Message-ID: <96A9C082-B4D9-494C-A00F-50FFA5DEB876@activestate.com>

Ah OK. I misunderstood (was thinking that env markets and prj url were added to another PEP).

-srid

On 2010-03-20, at 6:39 AM, Tarek Ziad? wrote:

> On Sat, Mar 20, 2010 at 3:33 AM, Sridhar Ratnakumar
> <sridharr at activestate.com> wrote:
> [..]
>> 
>> There's no tool out there that understand
>> PEP 345 / 1.2 yet.
>> 
>> Apparently pkginfo supports PEP 345 (see above).
> 
> 
> It's an old version of PEP 345. It misses for example:
> 
> - Project-Url
> - environment markers
> 
> I think Tres added PEP 345 support a while ago, and it needs an upgrade
> 
> Regards,
> Tarek
> -- 
> Tarek Ziad? | http://ziade.org


From tseaver at palladion.com  Sat Mar 20 18:14:42 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 20 Mar 2010 13:14:42 -0400
Subject: [Distutils] [buildout] How to configure python interpreter to
 use it with Google Appengine?
In-Reply-To: <5bb76e241003200954v7c0c9d64uda64398a15040008@mail.gmail.com>
References: <5bb76e241003200806j1e3bbdf2nfdb3a60a69907f94@mail.gmail.com>	
	<4BA4FBBA.6000201@palladion.com>
	<5bb76e241003200954v7c0c9d64uda64398a15040008@mail.gmail.com>
Message-ID: <4BA50282.3060505@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

?????? Lacrima wrote:

> Thanks for your reply, Tres! Here is my buildout.cfg:
> [buildout]
> develop = .
> parts = python test appengine
> 
> [python]
> recipe = zc.recipe.egg:scripts
> interpreter = python
> eggs = unikeeper
> 
> [test]
> recipe = pbp.recipe.noserunner
> eggs = unikeeper
> working-directory = ./src/keeper
> 
> [appengine]
> recipe = rod.recipe.appengine
> eggs = unikeeper
> server-script = dev_appserver
> exclude = unit_tests
>           doc_tests
>           unikeeper.egg-info
> url = http://googleappengine.googlecode.com/files/google_appengine_1.3.1.zip

It looks as though the google_appengine zipfile doesn't intend to be
installed in such a way as to make its libraries easily usable under
setuptools.  The rod.recipe.appenge recipe creates the script for
running the development environment, and puts 'parts/google_appengine'
on sys.path. I think you could use the 'extra-paths' argument to the
'zc.recipe.eggs:scripts' recipe to add that same path to your custom
interpreter, like so:

  [python]
  recipe = zc.recipe.eggs:scripts
  interpreter = python
  eggs = unikeeper
  extra-paths = ${buildout:directory}/parts/google_appengine


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkulAoIACgkQ+gerLs4ltQ5WNwCfXEfFucLseXXgWiFJIZVp1XMS
ih0AnRW+1pf9SqakrjkW1R6HiTlIaV5T
=hM5r
-----END PGP SIGNATURE-----

From marius at pov.lt  Sat Mar 20 18:39:15 2010
From: marius at pov.lt (Marius Gedminas)
Date: Sat, 20 Mar 2010 19:39:15 +0200
Subject: [Distutils] [buildout] selectively excluding site-packages
In-Reply-To: <4BA3BB65.7030606@industromatic.com>
References: <4BA0A364.8040500@simplistix.co.uk>
	<9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>
	<4BA35189.8050401@simplistix.co.uk>
	<5DB278AC-8CC2-4E87-A9B3-C691C90D859A@canonical.com>
	<4BA3BB65.7030606@industromatic.com>
Message-ID: <20100320173915.GA16494@fridge.pov.lt>

On Fri, Mar 19, 2010 at 12:59:01PM -0500, John Griessen wrote:
> Suppose I'm starting fresh, (newbie at this, but wanting stability and
> new features).  How do you best use buildout to "simply use a system
> Python without site-packages at all"?

I'm using virtualenv to isolate my buildouts from site-packages:

  virtualenv --no-site-packages venv
  venv/bin/python bootstrap.py
  bin/buildout

After step 2 you can forget that you have a virtualenv and use buildout
normally.

Marius Gedminas
-- 
The *REAL* Y2K is the year 2048.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100320/1c2605be/attachment.pgp>

From ziade.tarek at gmail.com  Sat Mar 20 20:57:37 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 20 Mar 2010 15:57:37 -0400
Subject: [Distutils] How to specific metadata version in setup.py?
In-Reply-To: <ho2ton$pjp$2@dough.gmane.org>
References: <CB12A953-7BCF-4FC2-86E9-FE4AE9069140@activestate.com>
	<94bdd2611003191422s286d669al66e17952e093506@mail.gmail.com>
	<94bdd2611003191427y4128219es328fe0de60eef6e0@mail.gmail.com>
	<B45F021B-C8B4-4DF9-8107-3114F6EC0AE2@activestate.com>
	<94bdd2611003191451h1f5994ecoa6dbec0edc2f9eb2@mail.gmail.com>
	<C60AD6F8-90B9-42AC-A54D-80BD1FF6D0AB@activestate.com>
	<94bdd2611003200639s2f933d0by3e48756ae4fb1a8f@mail.gmail.com>
	<ho2ton$pjp$2@dough.gmane.org>
Message-ID: <94bdd2611003201257m76795074va4314e44d8a9de4b@mail.gmail.com>

On Sat, Mar 20, 2010 at 12:39 PM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? wrote:
>> On Sat, Mar 20, 2010 at 3:33 AM, Sridhar Ratnakumar
>> <sridharr at activestate.com> wrote:
>> [..]
>>> There's no tool out there that understand
>>> PEP 345 / 1.2 yet.
>>>
>>> Apparently pkginfo supports PEP 345 (see above).
>>
>>
>> It's an old version of PEP 345. It misses for example:
>>
>> - Project-Url
>> - environment markers
>>
>> I think Tres added PEP 345 support a while ago, and it needs an upgrade
>
> I'm happy to take patches which add support for parsing the extra fields
> and environment syntac, but given that no tools are *emitting* them yet,
> I'm not likely to get around to adding them myself for a bit.
>
> ?$ bzr co lp:~tseaver/pkginfo/trunk
>
> :)
>

I am planning to release a first alpha of distutils2 sometimes in
April, as soon as I have finished the implementation on PyPI side, so
it can accept these new fields. So that will be the first tool that
emit them.

Next, I think the pkginfo project is very close to the new
DistutilsMetadata class in distutils2 : it write *and* reads
the PKG-INFO file, so I am more likely to focus on the distutils2
implementation at this point.

Regards,
Tarek

-- 
Tarek Ziad? | http://ziade.org

From tseaver at palladion.com  Sat Mar 20 22:05:20 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 20 Mar 2010 17:05:20 -0400
Subject: [Distutils] [buildout] How to configure python interpreter to
 use it with Google Appengine?
In-Reply-To: <5bb76e241003201208o5a3be139o7ab9a2a4d6115ced@mail.gmail.com>
References: <5bb76e241003200806j1e3bbdf2nfdb3a60a69907f94@mail.gmail.com>	
	<4BA4FBBA.6000201@palladion.com>	
	<5bb76e241003200954v7c0c9d64uda64398a15040008@mail.gmail.com>	
	<4BA50282.3060505@palladion.com>
	<5bb76e241003201208o5a3be139o7ab9a2a4d6115ced@mail.gmail.com>
Message-ID: <4BA53890.6090300@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

?????? Lacrima wrote:

> Thanks! You have pointed the right direction.
> I have had to add following list of paths in order to make custom
> interpreter work as expected:
> .../parts/google_appengine
> .../parts/google_appengine/lib/antlr3
> .../parts/google_appengine/lib/django
> .../parts/google_appengine/lib/ipaddr
> .../parts/google_appengine/lib/webob
> .../parts/google_appengine/lib/yaml/lib
> 
> Thanks again for the help!

Glad that worked!


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkulOIsACgkQ+gerLs4ltQ41nQCgu3ej6tVq4aVuQlxVYdnoouXP
vLQAnidB1HkJuJIzgwajeAo9SXpcC2Zu
=VRzi
-----END PGP SIGNATURE-----

From janssen at parc.com  Mon Mar 22 02:45:21 2010
From: janssen at parc.com (Bill Janssen)
Date: Sun, 21 Mar 2010 18:45:21 PDT
Subject: [Distutils] problem with bdist_msi post-install script
Message-ID: <67213.1269222321@parc.com>

When I try to include a post-install script in my MSI built with
bdist_msi, it seem to be included and unpacked properly, but it doesn't
run successfully.  Here's what's in the script (after unpacking):


#!c:\Python26\python.exe

# do nothing much
import sys, os, time
print "Hello, World"

time.sleep(10)
sys.exit(0)


And here's what I get in my install log (generated with
"msiexec /i foo.msi /L*v foo.log"):


Action 18:35:46: install_script. 
Action start 18:35:46: install_script.
MSI (s) (40:E0) [18:35:46:882]: Note: 1: 1722 2: install_script 3: C:\Python26\\python.exe 4: C:\Python26\Scripts\foo-install-script.py 
MSI (s) (40:E0) [18:35:46:882]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (c) (FC:78) [18:35:46:902]: Note: 1: 2262 2: Error 3: -2147287038 
DEBUG: Error 2835:  The control ErrorIcon was not found on dialog ErrorDlg
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2835. The arguments are: ErrorIcon, ErrorDlg, 
Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action install_script, location: C:\Python26\\python.exe, command: C:\Python26\Scripts\foo-install-script.py 
MSI (s) (40:E0) [18:35:50:978]: Note: 1: 2262 2: Error 3: -2147287038 


Any ideas?  What's a postinstall script supposed to return or exit with
to indicate success or failure, anyway?

What does "The control ErrorIcon was not found on dialog ErrorDlg" mean?

Bill

From ziade.tarek at gmail.com  Mon Mar 22 02:58:42 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 21 Mar 2010 21:58:42 -0400
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <67213.1269222321@parc.com>
References: <67213.1269222321@parc.com>
Message-ID: <94bdd2611003211858t53518f2x7f41af19c69512d9@mail.gmail.com>

On Sun, Mar 21, 2010 at 9:45 PM, Bill Janssen <janssen at parc.com> wrote:
> When I try to include a post-install script in my MSI built with
> bdist_msi, it seem to be included and unpacked properly, but it doesn't
> run successfully. ?Here's what's in the script (after unpacking):
>
>
> #!c:\Python26\python.exe
>
> # do nothing much
> import sys, os, time
> print "Hello, World"
>
> time.sleep(10)
> sys.exit(0)
>
>
> And here's what I get in my install log (generated with
> "msiexec /i foo.msi /L*v foo.log"):
>
>
> Action 18:35:46: install_script.
> Action start 18:35:46: install_script.
> MSI (s) (40:E0) [18:35:46:882]: Note: 1: 1722 2: install_script 3: C:\Python26\\python.exe 4: C:\Python26\Scripts\foo-install-script.py
> MSI (s) (40:E0) [18:35:46:882]: Note: 1: 2262 2: Error 3: -2147287038
> MSI (c) (FC:78) [18:35:46:902]: Note: 1: 2262 2: Error 3: -2147287038
> DEBUG: Error 2835: ?The control ErrorIcon was not found on dialog ErrorDlg
> The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2835. The arguments are: ErrorIcon, ErrorDlg,
> Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. ?Action install_script, location: C:\Python26\\python.exe, command: C:\Python26\Scripts\foo-install-script.py
> MSI (s) (40:E0) [18:35:50:978]: Note: 1: 2262 2: Error 3: -2147287038
>
>
> Any ideas? ?What's a postinstall script supposed to return or exit with
> to indicate success or failure, anyway?
>
> What does "The control ErrorIcon was not found on dialog ErrorDlg" mean?


The only reference to ErrorIcon was commented out by Martin a while
ago. It was the icon attached to
the Error Dialog you.  I am not sure why you get this error.

MacZiade:command tarek$ svn blame bdist_msi.py |grep ErrorIcon
 42847 martin.v.loewis         #error.control("ErrorIcon", "Icon", 15,
9, 24, 24, 5242881, None, "py.ico", None, None)


I am cc'ing him.

>
> Bill
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From janssen at parc.com  Mon Mar 22 06:51:58 2010
From: janssen at parc.com (Bill Janssen)
Date: Sun, 21 Mar 2010 22:51:58 PDT
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <94bdd2611003211858t53518f2x7f41af19c69512d9@mail.gmail.com>
References: <67213.1269222321@parc.com>
	<94bdd2611003211858t53518f2x7f41af19c69512d9@mail.gmail.com>
Message-ID: <75770.1269237118@parc.com>

Thanks, Tarek.

I think I see why he commented it out -- there's the issue of having
your hands on the .ico bits when you need them.  Though it does seem
that the MSI installer requires it in spite of the docs.  But the real
problem turns out to be in the add_scripts() method.

Right now, it starts out

    def add_scripts(self):
        if self.install_script:
            add_data(self.db, "CustomAction",
                    [("install_script", 50, "PYTHON", self.install_script_key)])
            add_data(self.db, "InstallExecuteSequence",
                    [("install_script", "NOT Installed", 6800)])

But if the target dir has a space in the path, this command invocation
will fail, because Python will only see the first part of the path name.

If I add double-quotes around the install script name, it works:

    def add_scripts(self):
        if self.install_script:
            # need to quote install_script_key here to pass pathnames containing
            # spaces (like "Program Files") through
            add_data(self.db, "CustomAction",
                    [("install_script", 50, "PYTHON", '"' + self.install_script_key + '"')])
            add_data(self.db, "InstallExecuteSequence",
                    [("install_script", "NOT Installed", 6800)])

And, my other question, was, how should the script exit?  Seems that
sys.exit(0) works just fine.

Bill


Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> On Sun, Mar 21, 2010 at 9:45 PM, Bill Janssen <janssen at parc.com> wrote:
> > When I try to include a post-install script in my MSI built with
> > bdist_msi, it seem to be included and unpacked properly, but it doesn't
> > run successfully. ?Here's what's in the script (after unpacking):
> >
> >
> > #!c:\Python26\python.exe
> >
> > # do nothing much
> > import sys, os, time
> > print "Hello, World"
> >
> > time.sleep(10)
> > sys.exit(0)
> >
> >
> > And here's what I get in my install log (generated with
> > "msiexec /i foo.msi /L*v foo.log"):
> >
> >
> > Action 18:35:46: install_script.
> > Action start 18:35:46: install_script.
> > MSI (s) (40:E0) [18:35:46:882]: Note: 1: 1722 2: install_script 3: C:\Python26\\python.exe 4: C:\Python26\Scripts\foo-install-script.py
> > MSI (s) (40:E0) [18:35:46:882]: Note: 1: 2262 2: Error 3: -2147287038
> > MSI (c) (FC:78) [18:35:46:902]: Note: 1: 2262 2: Error 3: -2147287038
> > DEBUG: Error 2835: ?The control ErrorIcon was not found on dialog ErrorDlg
> > The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2835. The arguments are: ErrorIcon, ErrorDlg,
> > Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. ?Action install_script, location: C:\Python26\\python.exe, command: C:\Python26\Scripts\foo-install-script.py
> > MSI (s) (40:E0) [18:35:50:978]: Note: 1: 2262 2: Error 3: -2147287038
> >
> >
> > Any ideas? ?What's a postinstall script supposed to return or exit with
> > to indicate success or failure, anyway?
> >
> > What does "The control ErrorIcon was not found on dialog ErrorDlg" mean?
> 
> 
> The only reference to ErrorIcon was commented out by Martin a while
> ago. It was the icon attached to
> the Error Dialog you.  I am not sure why you get this error.
> 
> MacZiade:command tarek$ svn blame bdist_msi.py |grep ErrorIcon
>  42847 martin.v.loewis         #error.control("ErrorIcon", "Icon", 15,
> 9, 24, 24, 5242881, None, "py.ico", None, None)
> 
> 
> I am cc'ing him.
> 
> >
> > Bill
> > _______________________________________________
> > Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> > http://mail.python.org/mailman/listinfo/distutils-sig
> >
> 
> 
> 
> -- 
> Tarek Ziad? | http://ziade.org

From chris at simplistix.co.uk  Mon Mar 22 09:59:50 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 22 Mar 2010 08:59:50 +0000
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <5e5cdb041003190824t47d48091s6bcf6602a3b00ca7@mail.gmail.com>
References: <4B9F40B3.90401@simplistix.co.uk>	
	<4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>
	<5e5cdb041003190824t47d48091s6bcf6602a3b00ca7@mail.gmail.com>
Message-ID: <4BA73186.8090304@simplistix.co.uk>

Saint Germain wrote:
> I'm currently trying more or less the same thing by combining buildout
> with virtualenv and pip.

This doesn't seem like a sane thing to do.

These tools attempt to address the same problems in different ways.
Attempting to mash them together as it appears you have does nothing but 
result in an overcomplicated solution that's likely to be more fragile 
than if you'd worked with either buildout or pip/virtualenv on their own.

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From saintger at gmail.com  Mon Mar 22 10:20:42 2010
From: saintger at gmail.com (Saint Germain)
Date: Mon, 22 Mar 2010 10:20:42 +0100
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4BA73186.8090304@simplistix.co.uk>
References: <4B9F40B3.90401@simplistix.co.uk>
	<4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>
	<5e5cdb041003190824t47d48091s6bcf6602a3b00ca7@mail.gmail.com>
	<4BA73186.8090304@simplistix.co.uk>
Message-ID: <5e5cdb041003220220v2c642f6ay8f01cdfcbeb85126@mail.gmail.com>

2010/3/22 Chris Withers <chris at simplistix.co.uk>:

>> I'm currently trying more or less the same thing by combining buildout
>> with virtualenv and pip.
>
> This doesn't seem like a sane thing to do.
>
> These tools attempt to address the same problems in different ways.
> Attempting to mash them together as it appears you have does nothing but
> result in an overcomplicated solution that's likely to be more fragile than
> if you'd worked with either buildout or pip/virtualenv on their own.
>

Well I mainly wanted to set up environment using virtualenv+pip and it
worked pretty well.
However there were a lot of steps involved and I wanted to automated
the process.
So I just get the virtualenv + pip recipe and voil? !
Nothing overcomplicated, and a fallback to manually install everything
is always possible (indeed with the recipe, it's very simple, and they
are just a mean to automatically call virtualenv or pip).

I thought that buildout was designed for just that, am I wrong ?

From chris at simplistix.co.uk  Mon Mar 22 10:21:12 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 22 Mar 2010 09:21:12 +0000
Subject: [Distutils] [buildout] selectively excluding site-packages
In-Reply-To: <5DB278AC-8CC2-4E87-A9B3-C691C90D859A@canonical.com>
References: <4BA0A364.8040500@simplistix.co.uk>
	<9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>
	<4BA35189.8050401@simplistix.co.uk>
	<5DB278AC-8CC2-4E87-A9B3-C691C90D859A@canonical.com>
Message-ID: <4BA73688.4020109@simplistix.co.uk>

Gary Poster wrote:
>> Are these any docs on the new features on that branch? If so, where should I look?
> 
> The user-visible part of the changes is in the z3c.recipe.scripts recipe contained within the zc.buildout checkout, like zc.recipe.egg.

Sorry, you lost me there... I thought z3c.recipe.scripts was another 
package entirely. Have you merged it into zc.buildout? If so, why?

> Note that mixing a system python's site-packages and buildout eggs will, in my guess, always be less stable

Hmm, I guess you just need to make sure that the buildout manages the 
system packages too... There must be a recipe which drive aptitude 
around somewhere?

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Mon Mar 22 10:22:47 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 22 Mar 2010 09:22:47 +0000
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <5e5cdb041003220220v2c642f6ay8f01cdfcbeb85126@mail.gmail.com>
References: <4B9F40B3.90401@simplistix.co.uk>	
	<4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>	
	<5e5cdb041003190824t47d48091s6bcf6602a3b00ca7@mail.gmail.com>	
	<4BA73186.8090304@simplistix.co.uk>
	<5e5cdb041003220220v2c642f6ay8f01cdfcbeb85126@mail.gmail.com>
Message-ID: <4BA736E7.3040409@simplistix.co.uk>

Saint Germain wrote:
> 2010/3/22 Chris Withers <chris at simplistix.co.uk>:
> 
>>> I'm currently trying more or less the same thing by combining buildout
>>> with virtualenv and pip.
>> This doesn't seem like a sane thing to do.
>>
>> These tools attempt to address the same problems in different ways.
>> Attempting to mash them together as it appears you have does nothing but
>> result in an overcomplicated solution that's likely to be more fragile than
>> if you'd worked with either buildout or pip/virtualenv on their own.
>>
> 
> Well I mainly wanted to set up environment using virtualenv+pip and it
> worked pretty well.

Then why not just use virtualenv+pip with a custom bootstrap script?!

> I thought that buildout was designed for just that, am I wrong ?

It's a bit like using Subversion to manage a set of CVS checkouts...

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From martin at v.loewis.de  Mon Mar 22 10:40:49 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 22 Mar 2010 10:40:49 +0100
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <94bdd2611003211858t53518f2x7f41af19c69512d9@mail.gmail.com>
References: <67213.1269222321@parc.com>
	<94bdd2611003211858t53518f2x7f41af19c69512d9@mail.gmail.com>
Message-ID: <4BA73B21.6040005@v.loewis.de>


> The only reference to ErrorIcon was commented out by Martin a while
> ago. It was the icon attached to the Error Dialog you.

I'm not quite sure why I commented this out. See whether adding it back
fixes the problem.

The only reason I can see now is that py.ico isn't really an appropriate
error icon, instead, a stop sign or something like that should be used -
I may not have known then (as I don't know now) how to get that into the
MSI file.

Regards,
Martin

From martin at v.loewis.de  Mon Mar 22 10:37:03 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 22 Mar 2010 10:37:03 +0100
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <67213.1269222321@parc.com>
References: <67213.1269222321@parc.com>
Message-ID: <4BA73A3F.30904@v.loewis.de>

> MSI (s) (40:E0) [18:35:46:882]: Note: 1: 1722 2: install_script 3: C:\Python26\\python.exe 4: C:\Python26\Scripts\foo-install-script.py 

This means:

There is a problem with this Windows Installer package. A program run as
part of the setup did not finish as expected. Contact your support
personnel or package vendor. Action [2], location: [3], command: [4]

> MSI (s) (40:E0) [18:35:50:978]: Note: 1: 2262 2: Error 3: -2147287038 

This means:

Stream does not exist: [2]. System error: [3].

> 
> What does "The control ErrorIcon was not found on dialog ErrorDlg" mean?

It probably means it couldn't post the error message for the first
error, because the icon to indicate "error" isn't included in the MSI
file (which is a separate bug).

> What's a postinstall script supposed to return or exit
> with to indicate success or failure, anyway?

It should return 0 as the exit code.

> Any ideas?

I can think of two reasons:
a) it may dislike the double-backslash in the Python path. Try removing
one of them
b) the command line may need to repeat the executable name as argv0.

I would use orca (from the platform SDK) to edit the MSI file, and see
whether this fixes anything.

Regards,
Martin




From saintger at gmail.com  Mon Mar 22 11:37:14 2010
From: saintger at gmail.com (Saint Germain)
Date: Mon, 22 Mar 2010 11:37:14 +0100
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4BA736E7.3040409@simplistix.co.uk>
References: <4B9F40B3.90401@simplistix.co.uk>
	<4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>
	<5e5cdb041003190824t47d48091s6bcf6602a3b00ca7@mail.gmail.com>
	<4BA73186.8090304@simplistix.co.uk>
	<5e5cdb041003220220v2c642f6ay8f01cdfcbeb85126@mail.gmail.com>
	<4BA736E7.3040409@simplistix.co.uk>
Message-ID: <5e5cdb041003220337h347f1ba1p50332d107bc86e20@mail.gmail.com>

2010/3/22 Chris Withers <chris at simplistix.co.uk>:
> Saint Germain wrote:
>>
>> 2010/3/22 Chris Withers <chris at simplistix.co.uk>:
>>
>>>> I'm currently trying more or less the same thing by combining buildout
>>>> with virtualenv and pip.
>>>
>>> This doesn't seem like a sane thing to do.
>>>
>>> These tools attempt to address the same problems in different ways.
>>> Attempting to mash them together as it appears you have does nothing but
>>> result in an overcomplicated solution that's likely to be more fragile
>>> than
>>> if you'd worked with either buildout or pip/virtualenv on their own.
>>>
>>
>> Well I mainly wanted to set up environment using virtualenv+pip and it
>> worked pretty well.
>
> Then why not just use virtualenv+pip with a custom bootstrap script?!

Well because buildout makes all this very efficiently and simply. All
the options (find-links, newest, etc...) are already there.
Basically if I try to make a custom bootsrap script, I will end up
with more or less the same buildout.cfg, I will have to manage all the
options and the interaction, etc. For the error, I will have to have
my own error management.

Even for bootstrapping, I will have to download the same ez_setup in
order to easy_install what I want.

In addition, if I want to introduce some external C libraries, putting
this in my bootstrap will be some kind of hack. In buildout, I just
have to call the cmmi recipe, and voil?.

Really I don't see the point of trying to create from scratch my own
bootstrap script when buildout make all this so simple.

>> I thought that buildout was designed for just that, am I wrong ?
>
> It's a bit like using Subversion to manage a set of CVS checkouts...
>

I don't think that the comparison is fair.

From gary.poster at canonical.com  Mon Mar 22 15:15:40 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Mon, 22 Mar 2010 10:15:40 -0400
Subject: [Distutils] [buildout] selectively excluding site-packages
In-Reply-To: <4BA3E658.4010708@simplistix.co.uk>
References: <4BA0A364.8040500@simplistix.co.uk>	<9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>	<4BA35189.8050401@simplistix.co.uk>	<5DB278AC-8CC2-4E87-A9B3-C691C90D859A@canonical.com>	<4BA3BB65.7030606@industromatic.com>
	<9A49BD7D-5391-41BE-A5D9-4C11471F727A@canonical.com>
	<4BA3E658.4010708@simplistix.co.uk>
Message-ID: <9F713C2A-BAEF-4060-9FEF-448029390A10@canonical.com>


On Mar 19, 2010, at 5:02 PM, Chris Withers wrote:

> Gary Poster wrote:
>> If you are a newbie, I strongly suggest sticking with the released versions.  What I have done has zero guarantee of Jim merging it.
> 
> If he doesn't, how about a fork? ;-)

Rather not.

>> Moreover, the instructions on how a newbie can use this stuff from source are not worth my time or yours, IMO.
> 
> I'm not so sure, can't see what should prevent a new user trying all of this...

They would need to make eggs or sdists and put them in a download-cache, for instance.  If you'd like to volunteer the support, go for it. :-)

> 
>> On the other hand, if you are asking how you *would* use a system Python if my branches were merged, you would use the new version of zc.buildout, and use z3c.recipe.scripts where you normally would have used zc.recipe.egg,
> 
> Why is z3c.recipe.scripts required?

Backwards compatibility.  It has the new behavior.  zc.recipe.eggs has the old behavior.

Gary


From gary.poster at canonical.com  Mon Mar 22 15:20:43 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Mon, 22 Mar 2010 10:20:43 -0400
Subject: [Distutils] [buildout] selectively excluding site-packages
In-Reply-To: <4BA73688.4020109@simplistix.co.uk>
References: <4BA0A364.8040500@simplistix.co.uk>
	<9BA4E273-D025-4FD5-A862-33B2B449E3EF@canonical.com>
	<4BA35189.8050401@simplistix.co.uk>
	<5DB278AC-8CC2-4E87-A9B3-C691C90D859A@canonical.com>
	<4BA73688.4020109@simplistix.co.uk>
Message-ID: <516A24FC-CBF8-44B7-AE6B-DC4F212F5A96@canonical.com>


On Mar 22, 2010, at 5:21 AM, Chris Withers wrote:

> Gary Poster wrote:
>>> Are these any docs on the new features on that branch? If so, where should I look?
>> The user-visible part of the changes is in the z3c.recipe.scripts recipe contained within the zc.buildout checkout, like zc.recipe.egg.
> 
> Sorry, you lost me there... I thought z3c.recipe.scripts was another package entirely.

Yes

> Have you merged it into zc.buildout?

Yes

> If so, why?

The same kind of reason that zc.buildout.eggs is part of the buildout checkout.  The buildout tests rely on the functionality that z3c.recipe.scripts provides.

>> Note that mixing a system python's site-packages and buildout eggs will, in my guess, always be less stable
> 
> Hmm, I guess you just need to make sure that the buildout manages the system packages too... There must be a recipe which drive aptitude around somewhere?

Not to my knowledge.

Gary


From janssen at parc.com  Mon Mar 22 15:21:05 2010
From: janssen at parc.com (Bill Janssen)
Date: Mon, 22 Mar 2010 07:21:05 PDT
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <4BA73A3F.30904@v.loewis.de>
References: <67213.1269222321@parc.com> <4BA73A3F.30904@v.loewis.de>
Message-ID: <70620.1269267665@parc.com>

Martin v. L?wis <martin at v.loewis.de> wrote:

> > What does "The control ErrorIcon was not found on dialog ErrorDlg" mean?
> 
> It probably means it couldn't post the error message for the first
> error, because the icon to indicate "error" isn't included in the MSI
> file (which is a separate bug).

Yes, I started getting better errors when I added an icon back in.

> > What's a postinstall script supposed to return or exit
> > with to indicate success or failure, anyway?
> 
> It should return 0 as the exit code.

Thanks.  What if there's actually an error?  Just throw an exception?

> > Any ideas?
> 
> I can think of two reasons:
> a) it may dislike the double-backslash in the Python path. Try removing
> one of them

I was wondering about that.  There's this clause in add_find_python:

        add_data(self.db, "CustomAction",
                [("PythonFromMachine", 51+256, "PYTHONDIR", "[PYTHON.MACHINE]"),
                 ("PythonFromUser", 51+256, "PYTHONDIR", "[PYTHON.USER]"),
                 ("PythonExe", 51+256, "PYTHON", "[PYTHONDIR]\\python.exe"),
                 ("InitialTargetDir", 51+256, "TARGETDIR", "[PYTHONDIR]")])

and the backslash there seems redundant.  Changing it to
"[PYTHONDIR]python.exe" removes the extra backslash in the value of
PYTHON.  Shall I file a patch?

> b) the command line may need to repeat the executable name as argv0.

No, but that first arg, the name of the script file, should be quoted.

> I would use orca (from the platform SDK) to edit the MSI file, and see
> whether this fixes anything.

OK, thanks.

Bill

From janssen at parc.com  Mon Mar 22 15:26:48 2010
From: janssen at parc.com (Bill Janssen)
Date: Mon, 22 Mar 2010 07:26:48 PDT
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <4BA73B21.6040005@v.loewis.de>
References: <67213.1269222321@parc.com>
	<94bdd2611003211858t53518f2x7f41af19c69512d9@mail.gmail.com>
	<4BA73B21.6040005@v.loewis.de>
Message-ID: <70661.1269268008@parc.com>

Martin v. L?wis <martin at v.loewis.de> wrote:

> 
> > The only reference to ErrorIcon was commented out by Martin a while
> > ago. It was the icon attached to the Error Dialog you.
> 
> I'm not quite sure why I commented this out. See whether adding it back
> fixes the problem.

Yes, it gets rid of the secondary error, the bit about ErrorIcon and ErrorDlg.

> The only reason I can see now is that py.ico isn't really an appropriate
> error icon, instead, a stop sign or something like that should be used -
> I may not have known then (as I don't know now) how to get that into the
> MSI file.

Well, in http://svn.python.org/projects/sandbox/branches/MvL/msi/msi.py:

   # Bitmaps
    add_data(db, "Binary",
             [("PythonWin", msilib.Binary(srcdir+r"\PCbuild\installer.bmp")),
              ("Up",msilib.Binary("Up.bin")),
              ("New",msilib.Binary("New.bin")),
              ("InfoIcon",msilib.Binary("info.bin")),
              ("ExclamationIcon",msilib.Binary("exclamic.bin")),
             ])

Doesn't this work?

Bill

From martin at v.loewis.de  Mon Mar 22 15:53:54 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 22 Mar 2010 15:53:54 +0100
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <70620.1269267665@parc.com>
References: <67213.1269222321@parc.com> <4BA73A3F.30904@v.loewis.de>
	<70620.1269267665@parc.com>
Message-ID: <4BA78482.9010409@v.loewis.de>

>>> What's a postinstall script supposed to return or exit
>>> with to indicate success or failure, anyway?
>> It should return 0 as the exit code.
> 
> Thanks.  What if there's actually an error?  Just throw an exception?

Installer will look for a non-zero exit. It will display it as "a action
has failed". So how you arrive at the non-zero exit code is irrelevant.

> I was wondering about that.  There's this clause in add_find_python:
> 
>         add_data(self.db, "CustomAction",
>                 [("PythonFromMachine", 51+256, "PYTHONDIR", "[PYTHON.MACHINE]"),
>                  ("PythonFromUser", 51+256, "PYTHONDIR", "[PYTHON.USER]"),
>                  ("PythonExe", 51+256, "PYTHON", "[PYTHONDIR]\\python.exe"),
>                  ("InitialTargetDir", 51+256, "TARGETDIR", "[PYTHONDIR]")])
> 
> and the backslash there seems redundant.  Changing it to
> "[PYTHONDIR]python.exe" removes the extra backslash in the value of
> PYTHON.  Shall I file a patch?

Sure. Please indicate whether this is just cosmetical (and if so, better
file a patch for trunk, which has that code changed).

Regards,
Martin

From martin at v.loewis.de  Mon Mar 22 16:00:30 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 22 Mar 2010 16:00:30 +0100
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <70661.1269268008@parc.com>
References: <67213.1269222321@parc.com>
	<94bdd2611003211858t53518f2x7f41af19c69512d9@mail.gmail.com>
	<4BA73B21.6040005@v.loewis.de> <70661.1269268008@parc.com>
Message-ID: <4BA7860E.3050109@v.loewis.de>

> Well, in http://svn.python.org/projects/sandbox/branches/MvL/msi/msi.py:
> 
>    # Bitmaps
>     add_data(db, "Binary",
>              [("PythonWin", msilib.Binary(srcdir+r"\PCbuild\installer.bmp")),
>               ("Up",msilib.Binary("Up.bin")),
>               ("New",msilib.Binary("New.bin")),
>               ("InfoIcon",msilib.Binary("info.bin")),
>               ("ExclamationIcon",msilib.Binary("exclamic.bin")),
>              ])
> 
> Doesn't this work?

See

http://svn.python.org/projects/sandbox/branches/MvL/msi/README.txt

I now remember the problem: the icons are "Microsoft Sample Source
Code", and I was unsure whether I can legally include them with Python.

It might be useful to look at a recent PSDK whether this license still
holds, and also whether there are CC icons somewhere that can be freely
used (or someone could draw icons and contribute them to Python).

Regards,
Martin

From janssen at parc.com  Mon Mar 22 16:19:22 2010
From: janssen at parc.com (Bill Janssen)
Date: Mon, 22 Mar 2010 08:19:22 PDT
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <4BA73A3F.30904@v.loewis.de>
References: <67213.1269222321@parc.com> <4BA73A3F.30904@v.loewis.de>
Message-ID: <71842.1269271162@parc.com>

Martin, here's another question.  The ability to add pre-install scripts
seems to be implemented:

        if self.pre_install_script:
            scriptfn = os.path.join(self.bdist_dir, "preinstall.bat")
            f = open(scriptfn, "w")
            # The batch file will be executed with [PYTHON], so that %1
            # is the path to the Python interpreter; %0 will be the path
            # of the batch file.
            # rem ="""
            # %1 %0
            # exit
            # """
            # <actual script>
            f.write('rem ="""\n%1 %0\nexit\n"""\n')
            f.write(open(self.pre_install_script).read())
            f.close()
            add_data(self.db, "Binary",
                [("PreInstall", msilib.Binary(scriptfn))
                ])
            add_data(self.db, "CustomAction",
                [("PreInstall", 2, "PreInstall", None)
                ])
            add_data(self.db, "InstallExecuteSequence",
                    [("PreInstall", "NOT Installed", 450)])

But this doesn't look quite complete.  I don't see where the Python
interpreter is actually invoked here.  (Cute trick swapping the args,
by the way).

Which is presumably why, in finalize_options, we find:

        if self.pre_install_script:
            raise DistutilsOptionError, "the pre-install-script feature is not yet implemented"

Shouldn't the custom action be this:

            add_data(self.db, "CustomAction",
                [("PreInstall", 2, "PreInstall", '"PYTHON"'),
                ])

Bill


From martin at v.loewis.de  Mon Mar 22 16:32:37 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 22 Mar 2010 16:32:37 +0100
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <71842.1269271162@parc.com>
References: <67213.1269222321@parc.com> <4BA73A3F.30904@v.loewis.de>
	<71842.1269271162@parc.com>
Message-ID: <4BA78D95.8040207@v.loewis.de>

> But this doesn't look quite complete.  I don't see where the Python
> interpreter is actually invoked here.  (Cute trick swapping the args,
> by the way).
> 
> Which is presumably why, in finalize_options, we find:
> 
>         if self.pre_install_script:
>             raise DistutilsOptionError, "the pre-install-script feature is not yet implemented"
> 
> Shouldn't the custom action be this:
> 
>             add_data(self.db, "CustomAction",
>                 [("PreInstall", 2, "PreInstall", '"PYTHON"'),
>                 ])

I don't remember the details, but one problem might have been that
custom action 2 is defined as "EXE file stored in a Binary table
stream." Not sure whether batch files are even allowed here.

In any case, the value should probably be '"[PYTHON]"', then so that the
property gets expanded.

Regards,
Martin

From janssen at parc.com  Mon Mar 22 17:51:28 2010
From: janssen at parc.com (Bill Janssen)
Date: Mon, 22 Mar 2010 09:51:28 PDT
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <4BA78D95.8040207@v.loewis.de>
References: <67213.1269222321@parc.com> <4BA73A3F.30904@v.loewis.de>
	<71842.1269271162@parc.com> <4BA78D95.8040207@v.loewis.de>
Message-ID: <73246.1269276688@parc.com>

Martin v. L?wis <martin at v.loewis.de> wrote:

> > But this doesn't look quite complete.  I don't see where the Python
> > interpreter is actually invoked here.  (Cute trick swapping the args,
> > by the way).
> > 
> > Which is presumably why, in finalize_options, we find:
> > 
> >         if self.pre_install_script:
> >             raise DistutilsOptionError, "the pre-install-script feature is not yet implemented"
> > 
> > Shouldn't the custom action be this:
> > 
> >             add_data(self.db, "CustomAction",
> >                 [("PreInstall", 2, "PreInstall", '"PYTHON"'),
> >                 ])
> 
> I don't remember the details, but one problem might have been that
> custom action 2 is defined as "EXE file stored in a Binary table
> stream." Not sure whether batch files are even allowed here.
> 
> In any case, the value should probably be '"[PYTHON]"', then so that the
> property gets expanded.

Ah, thanks.

Bill

From janssen at parc.com  Mon Mar 22 18:35:26 2010
From: janssen at parc.com (Bill Janssen)
Date: Mon, 22 Mar 2010 10:35:26 PDT
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <4BA78D95.8040207@v.loewis.de>
References: <67213.1269222321@parc.com> <4BA73A3F.30904@v.loewis.de>
	<71842.1269271162@parc.com> <4BA78D95.8040207@v.loewis.de>
Message-ID: <74385.1269279326@parc.com>

So, in add_ui(), I tried changing 

        error.control("ErrorIcon", "Icon", 15, 9, 24, 24, 5242881, None, "py.ico", None, None)

to

        error.control("ErrorIcon", "Icon", 15, 9, 24, 24, 5242881, None, None, None, None)

But I still get this (when I've enabled the pre-install script feature),
so I think this is a bug in MSI.

Now to figure out the pre-install problem, once I've put an icon back in the Dialog.

Action 10:32:02: PreInstall. 
Action start 10:32:02: PreInstall.
MSI (s) (2C:A8) [10:32:02:322]: Note: 1: 1721 2: PreInstall 3: C:\WINDOWS\Installer\MSIB4.tmp 4:  
MSI (s) (2C:A8) [10:32:02:322]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (c) (C8:68) [10:32:02:332]: Note: 1: 2262 2: Error 3: -2147287038 
DEBUG: Error 2835:  The control ErrorIcon was not found on dialog ErrorDlg
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2835. The arguments are: ErrorIcon, ErrorDlg, 
Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: PreInstall, location: C:\WINDOWS\Installer\MSIB4.tmp, command:  
MSI (s) (2C:A8) [10:32:05:286]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (2C:A8) [10:32:05:286]: Product: UpLib-1.7.9 -- Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: PreInstall, location: C:\WINDOWS\Installer\MSIB4.tmp, command:  

From janssen at parc.com  Mon Mar 22 18:48:19 2010
From: janssen at parc.com (Bill Janssen)
Date: Mon, 22 Mar 2010 10:48:19 PDT
Subject: [Distutils] problem with bdist_msi post-install script
In-Reply-To: <4BA78D95.8040207@v.loewis.de>
References: <67213.1269222321@parc.com> <4BA73A3F.30904@v.loewis.de>
	<71842.1269271162@parc.com> <4BA78D95.8040207@v.loewis.de>
Message-ID: <74478.1269280099@parc.com>

Martin v. L?wis <martin at v.loewis.de> wrote:

> > But this doesn't look quite complete.  I don't see where the Python
> > interpreter is actually invoked here.  (Cute trick swapping the args,
> > by the way).
> > 
> > Which is presumably why, in finalize_options, we find:
> > 
> >         if self.pre_install_script:
> >             raise DistutilsOptionError, "the pre-install-script feature is not yet implemented"
> > 
> > Shouldn't the custom action be this:
> > 
> >             add_data(self.db, "CustomAction",
> >                 [("PreInstall", 2, "PreInstall", '"PYTHON"'),
> >                 ])
> 
> I don't remember the details, but one problem might have been that
> custom action 2 is defined as "EXE file stored in a Binary table
> stream." Not sure whether batch files are even allowed here.

Apparently not.


MSI (s) (2C:A0) [10:44:12:462]: Doing action: PreInstall
Action 10:44:12: PreInstall. 
Action start 10:44:12: PreInstall.
MSI (s) (2C:A0) [10:44:12:492]: Note: 1: 1721 2: PreInstall 3: C:\WINDOWS\Installer\MSIB7.tmp 4: "C:\Python26\\python.exe" 
MSI (s) (2C:A0) [10:44:12:492]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (c) (6C:C4) [10:44:12:502]: Note: 1: 2262 2: Error 3: -2147287038 
DEBUG: Error 2888:  Executing the Binary view failed
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2888. The arguments are: Binary, , 
Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: PreInstall, location: C:\WINDOWS\Installer\MSIB7.tmp, command: "C:\Python26\\python.exe" 
MSI (s) (2C:A0) [10:44:14:545]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (2C:A0) [10:44:14:545]: Product: UpLib-1.7.9 -- Error 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: PreInstall, location: C:\WINDOWS\Installer\MSIB7.tmp, command: "C:\Python26\\python.exe" 

Action ended 10:44:14: PreInstall. Return value 3.


Looks like we need JScript (what can that do, though?) or VBScript.

By the way, the double backslashes don't seem to be a problem.

Bill

From martin at v.loewis.de  Mon Mar 22 21:25:55 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 22 Mar 2010 21:25:55 +0100
Subject: [Distutils] VBScript puzzle
In-Reply-To: <74478.1269280099@parc.com>
References: <67213.1269222321@parc.com> <4BA73A3F.30904@v.loewis.de>
	<71842.1269271162@parc.com> <4BA78D95.8040207@v.loewis.de>
	<74478.1269280099@parc.com>
Message-ID: <4BA7D253.9030805@v.loewis.de>

> Looks like we need JScript (what can that do, though?) or VBScript.

Not sure whether users could accept writing JScript or VBScript for
bdist_msi, so (atleast for bdist_msi), I would like to either support
Python pre-install scripts, or not support pre-install scripts at all.

The question is whether we could trick a VBScript into also being a
Python script.

As this might be an interesting puzzle to solve, I'd like to pose it to
the entire distutils-sig readership. So here is the problem again:

As a batch file, my attempt at having a batch file that is also a
Python script was to write it as

rem="""
%1 %0
exit
"""
<python code here>

This should have been run with argv[1] being the path to the Python
interpreter. As a batch file, the first line is a comment, the second
line runs Python, anbd the third line terminates the script (so it
doesn't consider the following lines). As a Python script, the first
block is a variable assignment, followed by the regular Python script.

Now (as Installer won't run batch files) we need the same as VBScript
(or, failing that, as JScript). The script would be computed at the time
of MSI generation.

TIA,
Martin

From regebro at gmail.com  Tue Mar 23 11:21:45 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Tue, 23 Mar 2010 11:21:45 +0100
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4BA73186.8090304@simplistix.co.uk>
References: <4B9F40B3.90401@simplistix.co.uk>
	<4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com> 
	<5e5cdb041003190824t47d48091s6bcf6602a3b00ca7@mail.gmail.com> 
	<4BA73186.8090304@simplistix.co.uk>
Message-ID: <319e029f1003230321q218f9c7ahc02af8603b34dc8c@mail.gmail.com>

On Mon, Mar 22, 2010 at 09:59, Chris Withers <chris at simplistix.co.uk> wrote:
> Saint Germain wrote:
>>
>> I'm currently trying more or less the same thing by combining buildout
>> with virtualenv and pip.
>
> This doesn't seem like a sane thing to do.

Sure it does. It's just not very useful in most cases. Buildout by
itself works fine to isolate the python installation from the stuff
installed.
But if you want to also isolate the buildout from what's installed in
the python, then you can use virtualenv for that.

Unusual usecase, but sane. :)

From a.cavallo at cavallinux.eu  Tue Mar 23 11:38:12 2010
From: a.cavallo at cavallinux.eu (a.cavallo at cavallinux.eu)
Date: Tue, 23 Mar 2010 11:38:12 +0100
Subject: [Distutils] repeatable and updatable virtualenv
Message-ID: <36242.1269340692@cavallinux.eu>

Hi,
there's my little project running on the opensuse build server.

Actually it builds the latest subversion of python under the opt tree using the best 
practices in the field (nearly hands-off approach, integrating unit testing, repeatable etc).

http://pyvm.sourceforge.net

You can get an account and build the modules linking to these builds (automatically and overnight).

Regards,
Antonio Cavallo

Disclaimer. I'm the author and the only maintainer. For a living I work in QA if that matters to you.

 On Tue 23/03/10 11:21, "Lennart Regebro" regebro at gmail.com wrote:
> On Mon, Mar 22, 2010 at 09:59, Chris Withers <chris@
> simplistix.co.uk> wrote:
> Saint Germain wrote:
> >>
> >> I'm currently trying more or less the same thing
> by combining buildout
>> with virtualenv and pip.
> >
> > This doesn't seem like a sane thing to
> do.
> Sure it does. It's just not very useful in most cases. Buildout by
> itself works fine to isolate the python installation from the stuff
> installed.
> But if you want to also isolate the buildout from what's installed in
> the python, then you can use virtualenv for that.
> 
> Unusual usecase, but sane. :)
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
> 
> 


From lacrima.maxim at gmail.com  Tue Mar 23 13:15:05 2010
From: lacrima.maxim at gmail.com (=?UTF-8?B?0JzQsNC60YHQuNC8IExhY3JpbWE=?=)
Date: Tue, 23 Mar 2010 14:15:05 +0200
Subject: [Distutils] How to use Nose plugins with buildout
	pbp.recipe.noserunner recipe ?
Message-ID: <5bb76e241003230515u7e7e10efp777be51bf8ba67bf@mail.gmail.com>

Hello!

I've been using buildout. How can I install nose script with
pbp.recipe.noserunner recipe (or anything else), so that I can pass an
option to the script to enable plugin?
Specifically, I want to enable nose plugin for GAE: bin/nose --with-gae.

Thanks in advance.
Sorry, if my English isn't proper.

with regards,
Maxim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100323/639a9cfa/attachment.html>

From jess.austin at gmail.com  Tue Mar 23 21:57:22 2010
From: jess.austin at gmail.com (Jess Austin)
Date: Tue, 23 Mar 2010 14:57:22 -0600
Subject: [Distutils] VBScript puzzle
Message-ID: <b8ad139e1003231357t1310d253q8ba0e53434dee835@mail.gmail.com>

On Mon, 22 Mar 2010 at 21:25:55,  "Martin v. L?wis" <martin at v.loewis.de> wrote:
> As this might be an interesting puzzle to solve, I'd like to pose it to
> the entire distutils-sig readership. So here is the problem again:
>
> As a batch file, my attempt at having a batch file that is also a
> Python script was to write it as
>
> rem="""
> %1 %0
> exit
> """
> <python code here>
>
> This should have been run with argv[1] being the path to the Python
> interpreter. As a batch file, the first line is a comment, the second
> line runs Python, anbd the third line terminates the script (so it
> doesn't consider the following lines). As a Python script, the first
> block is a variable assignment, followed by the regular Python script.
>
> Now (as Installer won't run batch files) we need the same as VBScript
> (or, failing that, as JScript). The script would be computed at the time
> of MSI generation.

I couldn't get this to work as VBScript (that requires too many line
continuation characters), but I think the following JScript should
work.  The call to WShell.Run() pops another window, so I included a
time.sleep() call to make that slow enough to notice.  Fortunately
JScript and python both will happily ignore integer and string
literals at the beginning of the file, and JScript comments look like
python floor division.  I ran this at the command line like so:


C:\>cscript bdist.js "Python26\python.exe"


Here's the script:


4 // 3; '''
;
if (WScript.Arguments.Count() < 1)
  WScript.Echo("usage: " + WScript.ScriptName + " <path to python>");
else
  WScript.CreateObject("WScript.Shell").Run(WScript.Arguments.Item(0) + " " +
                                            WScript.ScriptFullName, 1, true); /*
'''
# start of python script
from time import sleep
print("hello from python")
sleep(5)
# end of python script */


HTH,
Jess

From martin at v.loewis.de  Tue Mar 23 23:21:23 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 23 Mar 2010 23:21:23 +0100
Subject: [Distutils] VBScript puzzle
In-Reply-To: <b8ad139e1003231357t1310d253q8ba0e53434dee835@mail.gmail.com>
References: <b8ad139e1003231357t1310d253q8ba0e53434dee835@mail.gmail.com>
Message-ID: <4BA93EE3.1030307@v.loewis.de>


> HTH,

That's really cute!

Thanks a lot,

Martin

From p.f.moore at gmail.com  Tue Mar 23 23:36:57 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 23 Mar 2010 22:36:57 +0000
Subject: [Distutils] VBScript puzzle
In-Reply-To: <b8ad139e1003231357t1310d253q8ba0e53434dee835@mail.gmail.com>
References: <b8ad139e1003231357t1310d253q8ba0e53434dee835@mail.gmail.com>
Message-ID: <79990c6b1003231536l5f1935dcweab4ce2f79161df5@mail.gmail.com>

On 23 March 2010 20:57, Jess Austin <jess.austin at gmail.com> wrote:
> I couldn't get this to work as VBScript (that requires too many line
> continuation characters), but I think the following JScript should
> work.

You are a deeply disturbed person :-)

That's seriously neat, in a scary sort of way...
Paul.

From jess.austin at gmail.com  Wed Mar 24 01:29:56 2010
From: jess.austin at gmail.com (Jess Austin)
Date: Tue, 23 Mar 2010 19:29:56 -0500
Subject: [Distutils] VBScript puzzle
In-Reply-To: <4BA93EE3.1030307@v.loewis.de>
References: <b8ad139e1003231357t1310d253q8ba0e53434dee835@mail.gmail.com>
	<4BA93EE3.1030307@v.loewis.de>
Message-ID: <b8ad139e1003231729q16f479fdv4847a2119bb0f74@mail.gmail.com>

On Tue, Mar 23, 2010 at 5:21 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> That's really cute!

Glad you like it!  I wrote another version, this time using
WshShell.Exec() rather than WshShell.Run().  This way everything
happens in the same terminal, although from random googling it seems
that Exec() may be rather racy (the fact that you can't just hook
WshScriptExec.StdOut to WScript.StdOut is kind of pathetic).  I've
also added some argument handling:


C:\>cscript bdist.js Python26\python.exe foo bar
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

hello from python
arguments: foo, bar

C:\>


Script:

4 // 3; '''
;
if (WScript.Arguments.length < 1)
{
  WScript.Echo("usage: " + WScript.ScriptName + " <path to python> [args for" +
               " python]");
  WScript.Quit();
}
var args = "";
for (i=1; i<WScript.Arguments.length; i++)
{
  args = args + " " + WScript.Arguments.Item(i);
}
var oExec = WScript.CreateObject("WScript.Shell")
                   .Exec(WScript.Arguments.Item(0) + " " +
                         WScript.ScriptFullName + args);
while (oExec.Status == 0)
{
  while (!oExec.StdOut.AtEndOfStream)
  {
    WScript.StdOut.WriteLine(oExec.StdOut.ReadLine());
  }
  while (!oExec.StdErr.AtEndOfStream)
  {
    WScript.StdErr.WriteLine(oExec.StdErr.ReadLine());
  }
  WScript.Sleep(100);
} /*
'''
# start of python script
from sys import argv
print("hello from python")
print("arguments: " + ", ".join(argv[1:]))
# end of python script */

From chris at simplistix.co.uk  Wed Mar 24 11:14:47 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 24 Mar 2010 10:14:47 +0000
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <319e029f1003230321q218f9c7ahc02af8603b34dc8c@mail.gmail.com>
References: <4B9F40B3.90401@simplistix.co.uk>
	<4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>
	<5e5cdb041003190824t47d48091s6bcf6602a3b00ca7@mail.gmail.com>
	<4BA73186.8090304@simplistix.co.uk>
	<319e029f1003230321q218f9c7ahc02af8603b34dc8c@mail.gmail.com>
Message-ID: <4BA9E617.2060903@simplistix.co.uk>

Lennart Regebro wrote:
> On Mon, Mar 22, 2010 at 09:59, Chris Withers <chris at simplistix.co.uk> wrote:
>> Saint Germain wrote:
>>> I'm currently trying more or less the same thing by combining buildout
>>> with virtualenv and pip.
>> This doesn't seem like a sane thing to do.
> 
> Sure it does. It's just not very useful in most cases. Buildout by
> itself works fine to isolate the python installation from the stuff
> installed.

Well, no, using a virtualenv to wrap a buildout is far from insane, 
especially until Gary's work to make site-packages optionally excluded 
from the search path lands!

However, the OP's recommended recipes appear to just use buildout to 
drive virtualenv, ignoring all of buildout's python package management.
That seems insane...

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

From ziade.tarek at gmail.com  Wed Mar 24 11:26:20 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 24 Mar 2010 11:26:20 +0100
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
Message-ID: <94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>

On Wed, Mar 24, 2010 at 10:59 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> I wonder if there are many people here who don't use some kind of
> "easy_install" package for package management in their Python /
> virtualenv installations? I propose to include at least one such
> package that is capable to auto-update itself in Python 2.7
>
> C:\~env\Python27>python.exe -m easy_install
> C:\~env\Python27\python.exe: No module named easy_install
>
> C:\~env\Python27>python.exe -m pip
> C:\~env\Python27\python.exe: No module named pip
>
>
> It bugs me when I have to troubleshoot things on yet another machine
> that doesn't have some kind of `setuptools` installed. Or when I have
> to test some bug in my package on different Python version with a
> clean install and need some dependencies.


We are working on distutils2 right now to improve the situation, and
Ian has proposed to work on the possible inclusion of virtualenv in
the stldib as well.

I'll talk for distutils2 :

The plan is to provide a distutils2 standalone version that can be
installed from 2.4 to 3.x, and that will provide a basic
installer/uninstaller via -m.

Distutils2 is planned to be reintegrated in the stdlib in Python 3.3,
and my goal is to release it when Python 2.7 final is released.

The open question is: do we want to include a full installer that
takes care of installing / removing dependencies as well ?

I think not. Pip already provides this feature on the top of distutils
(and distutils2 later I guess) and is not hard to install on the top
of Python.

But the "auto-update" story seems interesting, can you expand on this ?

Tarek

-- 
Tarek Ziad? | http://ziade.org

From agroszer at gmail.com  Wed Mar 24 11:38:17 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Wed, 24 Mar 2010 11:38:17 +0100
Subject: [Distutils] zc.buildout and "Not upgrading because not running a
	local buildout command"
Message-ID: <1011690799.20100324113817@gmail.com>

Hello,

Having problems here with the above.

The thing is that there should be two projects installed on the same
server, but the one is a zope KGS 3.4 the other is a
ztk/bluebream-ish.
The two have different version requirements for setuptools and
zc.buildout.
The buildout.cfg comes from the web like this:
buildout -t 2 -c http://mypypi.org/++projects++/proj/proj-stage-0.0.4.cfg
(On top of that this is driven by keas.build, but that should not
matter)
Buildout (1.4.1) is installed via easy_install and setuptools (0.6c9).
Therefore the message "Not upgrading because not running a local
buildout command". The message is reasonable, but still makes problems
in the way of making the one of the projects non-installable.

Would not it be easy to create a bin/buildout script and restart with
that?

Or is there any other sane solution for this (that I missed)?

-- 
Best regards,
 Adam GROSZER                          mailto:agroszer at gmail.com
--
Quote of the day:
Before Xerox, five carbons were the maximum extension of anybody's ego.


From techtonik at gmail.com  Wed Mar 24 12:20:19 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 24 Mar 2010 13:20:19 +0200
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
Message-ID: <d34314101003240420j57010ac3k71ba34cc0b2902fa@mail.gmail.com>

On Wed, Mar 24, 2010 at 12:26 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>
> Distutils2 is planned to be reintegrated in the stdlib in Python 3.3,
> and my goal is to release it when Python 2.7 final is released.

Does that means "after" Python 2.7, because I meant it to be "before"
or at least "with"?

> The open question is: do we want to include a full installer that
> takes care of installing / removing dependencies as well ?

If there is a risk to get nothing at all in 2.7 distribution, because
it just won't be ready/accepted by that time, then I it is certainly
optional.

> But the "auto-update" story seems interesting, can you expand on this ?

Sure. Package management tool should have an ability to update itself
when required regardless of Python release. For example::

    python.exe -m easy_install setuptools

This will get you new version of `setuptools` and `easy_install`
module from it automagically. You do not need to install new version
of `setuptools` manually or copy files from SVN if you want to see
fixes before next Python release. The stuff you would likely need to
do with distutils bugs, which I personally find awkward.

Package management is orthogonal to Python releases, and it is more
oriented at Python users who don't like to wait or follow PEPs. That's
why package management tool such as 'easy_install' has shorter
development cycle, and it should faster react to user feedback. What
can be one of the reasons that no package management tool is included
with Python.

In various README you may often see "requires setuptools > 0.6c9" or
similar. I can't see why package management tool can not detect this
dependency and propose to update itself.

If it is impossible to ship the whole package management system then
at least Python distribution may carry small bootstrap script for it.
When user tries to execute package management tools, it warns him that
these are not installed and gives a hint where to get them::

> python -m easy_install bla-bla-bla
Error: easy_install module is not shipped with this Python release.
Please execute the following command to install the latest version.

python -m easy_bootstrap

-- 
anatoly t.

From techtonik at gmail.com  Wed Mar 24 12:23:18 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 24 Mar 2010 13:23:18 +0200
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <d34314101003240420j57010ac3k71ba34cc0b2902fa@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<d34314101003240420j57010ac3k71ba34cc0b2902fa@mail.gmail.com>
Message-ID: <d34314101003240423n503b46c1i92580d4723313506@mail.gmail.com>

> Sure. Package management tool should have an ability to update itself when required regardless of Python release. For example::
>
> python.exe -m easy_install setuptools
>

This should be:

    python -m easy_install -U setuptools

P.S. Wave effect. =)
-- 
anatoly t.

From ziade.tarek at gmail.com  Wed Mar 24 12:30:19 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 24 Mar 2010 12:30:19 +0100
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <d34314101003240420j57010ac3k71ba34cc0b2902fa@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<d34314101003240420j57010ac3k71ba34cc0b2902fa@mail.gmail.com>
Message-ID: <94bdd2611003240430m1fb8f6e5o22fc24d204c043c9@mail.gmail.com>

On Wed, Mar 24, 2010 at 12:20 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Wed, Mar 24, 2010 at 12:26 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>
>> Distutils2 is planned to be reintegrated in the stdlib in Python 3.3,
>> and my goal is to release it when Python 2.7 final is released.
>
> Does that means "after" Python 2.7, because I meant it to be "before"
> or at least "with"?

The goal is to provide a first version by the time 2.7 is out.

>
>> The open question is: do we want to include a full installer that
>> takes care of installing / removing dependencies as well ?
>
> If there is a risk to get nothing at all in 2.7 distribution, because
> it just won't be ready/accepted by that time, then I it is certainly
> optional.
>

Understand that the distutils2 project is happening outside the stdlib
at this time,
so you will have to install it on the top of Python in any case.

Last, its release cycle will be shorter until it gets back in the
stdlib, that will make it easy
to add features.

>> But the "auto-update" story seems interesting, can you expand on this ?
>
> Sure. Package management tool should have an ability to update itself
> when required regardless of Python release. For example::
>
> ? ?python.exe -m easy_install setuptools
>
> This will get you new version of `setuptools` and `easy_install`
> module from it automagically. You do not need to install new version
> of `setuptools` manually or copy files from SVN if you want to see
> fixes before next Python release. The stuff you would likely need to
> do with distutils bugs, which I personally find awkward.
>
> Package management is orthogonal to Python releases, and it is more
> oriented at Python users who don't like to wait or follow PEPs. That's
> why package management tool such as 'easy_install' has shorter
> development cycle, and it should faster react to user feedback. What
> can be one of the reasons that no package management tool is included
> with Python.
>
> In various README you may often see "requires setuptools > 0.6c9" or
> similar. I can't see why package management tool can not detect this
> dependency and propose to update itself.
>
> If it is impossible to ship the whole package management system then
> at least Python distribution may carry small bootstrap script for it.
> When user tries to execute package management tools, it warns him that
> these are not installed and gives a hint where to get them::
>
>> python -m easy_install bla-bla-bla
> Error: easy_install module is not shipped with this Python release.
> Please execute the following command to install the latest version.
>
> python -m easy_bootstrap

Interesting, can you start a new thread on distutils-SIG for this
part, so we can discuss it there ?

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From dsdale24 at gmail.com  Wed Mar 24 12:50:44 2010
From: dsdale24 at gmail.com (Darren Dale)
Date: Wed, 24 Mar 2010 07:50:44 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
Message-ID: <a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>

On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> The open question is: do we want to include a full installer that
> takes care of installing / removing dependencies as well ?
>
> I think not. Pip already provides this feature on the top of distutils
> (and distutils2 later I guess) and is not hard to install on the top
> of Python.

Is pip able to determine and install dependencies recursively, like
easy_install does? Or is it up to the requested package to it specify
its dependencies (and its dependencies dependencies) in a pip
requirements file that is distributed separately?

Darren

From ziade.tarek at gmail.com  Wed Mar 24 12:53:01 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 24 Mar 2010 12:53:01 +0100
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
Message-ID: <94bdd2611003240453l79f7787ft101459a199a64061@mail.gmail.com>

On Wed, Mar 24, 2010 at 12:50 PM, Darren Dale <dsdale24 at gmail.com> wrote:
> On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> The open question is: do we want to include a full installer that
>> takes care of installing / removing dependencies as well ?
>>
>> I think not. Pip already provides this feature on the top of distutils
>> (and distutils2 later I guess) and is not hard to install on the top
>> of Python.
>
> Is pip able to determine and install dependencies recursively, like
> easy_install does? Or is it up to the requested package to it specify
> its dependencies (and its dependencies dependencies) in a pip
> requirements file that is distributed separately?

Pip uses the same standard: the install_requires option in setuptools,
that is put in a requires.txt file when the egg-info is computed.

Notice that we have defined this field in the new version of the
metadata (PEP 345) for future interoperability.

Let's remove python-dev for packaging talks in the next answers

Regards
Tarek

>
> Darren
>



-- 
Tarek Ziad? | http://ziade.org

From dsdale24 at gmail.com  Wed Mar 24 12:58:21 2010
From: dsdale24 at gmail.com (Darren Dale)
Date: Wed, 24 Mar 2010 07:58:21 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <94bdd2611003240453l79f7787ft101459a199a64061@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<94bdd2611003240453l79f7787ft101459a199a64061@mail.gmail.com>
Message-ID: <a08e5f81003240458g7afcd6d7pe5b19d22ff14304e@mail.gmail.com>

Hi Tarek,

On Wed, Mar 24, 2010 at 7:53 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Wed, Mar 24, 2010 at 12:50 PM, Darren Dale <dsdale24 at gmail.com> wrote:
>> On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>> The open question is: do we want to include a full installer that
>>> takes care of installing / removing dependencies as well ?
>>>
>>> I think not. Pip already provides this feature on the top of distutils
>>> (and distutils2 later I guess) and is not hard to install on the top
>>> of Python.
>>
>> Is pip able to determine and install dependencies recursively, like
>> easy_install does? Or is it up to the requested package to it specify
>> its dependencies (and its dependencies dependencies) in a pip
>> requirements file that is distributed separately?
>
> Pip uses the same standard: the install_requires option in setuptools,
> that is put in a requires.txt file when the egg-info is computed.
>
> Notice that we have defined this field in the new version of the
> metadata (PEP 345) for future interoperability.
>
> Let's remove python-dev for packaging talks in the next answers

Thanks for responding, but I'm still wondering if pip can install
dependencies recursively.

Darren

From ncoghlan at gmail.com  Wed Mar 24 13:02:06 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 24 Mar 2010 22:02:06 +1000
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <d34314101003240420j57010ac3k71ba34cc0b2902fa@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<d34314101003240420j57010ac3k71ba34cc0b2902fa@mail.gmail.com>
Message-ID: <4BA9FF3E.10009@gmail.com>

anatoly techtonik wrote:
> If it is impossible to ship the whole package management system then 
> at least Python distribution may carry small bootstrap script for it.
>  When user tries to execute package management tools, it warns him
> that these are not installed and gives a hint where to get them::
> 
>> python -m easy_install bla-bla-bla
> Error: easy_install module is not shipped with this Python release. 
> Please execute the following command to install the latest version.
> 
> python -m easy_bootstrap

Note that this idea has come up before and is *much* more likely to get
traction than including a full package management system.

The nature of package management is such that tying an installation
system to the release cycle of the core interpreter is unlikely to end
well. A bootstrapping tool that only knows how to download a single
specific package would be much easier to keep stable.

Even such a scaled back idea is still far from a certainty to be
accepted though, given the number of people who vehemently object to
duplicating any significant part of the functionality of the system
package management tools (i.e. RPM, apt et al).

At this point, the packaging story is in the hands of distutils-sig and
they're pressing forward with several initiatives that will permit the
construction of more robust and reliable Python-specific package
management systems (such as supporting listing and uninstallation of
installed packages).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From carl at dirtcircle.com  Wed Mar 24 13:12:47 2010
From: carl at dirtcircle.com (Carl Meyer)
Date: Wed, 24 Mar 2010 08:12:47 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
 for 2.7
In-Reply-To: <a08e5f81003240458g7afcd6d7pe5b19d22ff14304e@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>	<94bdd2611003240453l79f7787ft101459a199a64061@mail.gmail.com>
	<a08e5f81003240458g7afcd6d7pe5b19d22ff14304e@mail.gmail.com>
Message-ID: <4BAA01BF.30805@dirtcircle.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Darren,

Darren Dale wrote:
[snip]
> Thanks for responding, but I'm still wondering if pip can install
> dependencies recursively.

Yes, it can and does. As Tarek said, pip uses the same install_requires
metadata and it treats it the same way as easy_install, including
recursive install of dependencies.

This is mostly orthogonal to the requirements-file feature you
mentioned, which is a way to freeze a specific known "working set" of
package versions for a particular purpose. IMO requirements files are
most useful (in terms of avoiding unexpected breakage) when they freeze
the entire set of dependencies, but even when installing from a
requirements file, pip will automatically (and recursively) pursue any
needed install_requires dependencies that are not present in the
requirements file.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuqAb8ACgkQ1j/fhc23WEBqDgCgvdOkqBtBjgJHdak39oUuMEW9
O6oAoL03Ze5Jd7FaGWJr2wpuzrp5Q2h7
=oosr
-----END PGP SIGNATURE-----

From olemis at gmail.com  Wed Mar 24 13:22:23 2010
From: olemis at gmail.com (Olemis Lang)
Date: Wed, 24 Mar 2010 08:22:23 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <d34314101003240423n503b46c1i92580d4723313506@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<d34314101003240420j57010ac3k71ba34cc0b2902fa@mail.gmail.com>
	<d34314101003240423n503b46c1i92580d4723313506@mail.gmail.com>
Message-ID: <24ea26601003240522n3f44d8b5k8105a13d4fb614bf@mail.gmail.com>

On Wed, Mar 24, 2010 at 7:23 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>> Sure. Package management tool should have an ability to update itself when required regardless of Python release. For example::
>>
>> python.exe -m easy_install setuptools
>>
>
> This should be:
>
> ? ?python -m easy_install -U setuptools
>

JFTR

More precisely, what I use for CI is

{{{
#!sh

$ easy_install -U setuptools==dev
}}}

but the `python -m` part should work as well ;o)

PS: e.g. that allows to check out code from SVN in order to use
setuptools 0.7.x `test_runner` switch like this

{{{
python -W ignore::DeprecationWarning setup.py test -r ciutils:junitrunner
}}}

;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
TracRpc: API v2: Test cases for XML-RPC ... PASS -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/228ef43726b0/

From olemis at gmail.com  Wed Mar 24 13:27:03 2010
From: olemis at gmail.com (Olemis Lang)
Date: Wed, 24 Mar 2010 08:27:03 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
Message-ID: <24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>

On Wed, Mar 24, 2010 at 7:50 AM, Darren Dale <dsdale24 at gmail.com> wrote:
> On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> The open question is: do we want to include a full installer that
>> takes care of installing / removing dependencies as well ?
>>
>> I think not. Pip already provides this feature on the top of distutils
>> (and distutils2 later I guess) and is not hard to install on the top
>> of Python.
>
> Is pip able to determine and install dependencies recursively, like
> easy_install does? Or is it up to the requested package to it specify
> its dependencies (and its dependencies dependencies) in a pip
> requirements file that is distributed separately?
>

My experience is that only `install_requires` is needed (unless you
want to create app bundles AFAICR) , but in practice I've noticed that
*some* easy_installable packages are not pip-able (though I had no
time to figure out why :-/ )

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
On adding Hessian (RPC) support for Trac -
http://feedproxy.google.com/~r/simelo-en/~3/Vit6dRudChU/on-adding-hessian-rpc-support-for-trac.html

From dsdale24 at gmail.com  Wed Mar 24 14:15:37 2010
From: dsdale24 at gmail.com (Darren Dale)
Date: Wed, 24 Mar 2010 09:15:37 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <4BAA01BF.30805@dirtcircle.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<94bdd2611003240453l79f7787ft101459a199a64061@mail.gmail.com>
	<a08e5f81003240458g7afcd6d7pe5b19d22ff14304e@mail.gmail.com>
	<4BAA01BF.30805@dirtcircle.com>
Message-ID: <a08e5f81003240615m3d81148qa35bf14319e4024b@mail.gmail.com>

Hi Carl,

2010/3/24 Carl Meyer <carl at dirtcircle.com>:
> Darren Dale wrote:
> [snip]
>> Thanks for responding, but I'm still wondering if pip can install
>> dependencies recursively.
>
> Yes, it can and does. As Tarek said, pip uses the same install_requires
> metadata

I saw that part...

> and it treats it the same way as easy_install, including
> recursive install of dependencies.

and perhaps this was implied. Thanks for the clarification.

> This is mostly orthogonal to the requirements-file feature you
> mentioned, which is a way to freeze a specific known "working set" of
> package versions for a particular purpose. IMO requirements files are
> most useful (in terms of avoiding unexpected breakage) when they freeze
> the entire set of dependencies, but even when installing from a
> requirements file, pip will automatically (and recursively) pursue any
> needed install_requires dependencies that are not present in the
> requirements file.

Right, I am somewhat familiar with requirements files. I guess I have
not been keeping up closely enough with pip development recently. Last
I checked, pip supported dependencies via requirements files (which
are good for setting up applications in isolated environments) but not
recursively and not without a requirements file like easy_install does
(which is good for libraries, and for setting up general-use
environments like ~/.local/lib/python/site-packages). I think
requirements files may not be quite as useful in the numerical and
scientific community as they are in yours. So I am happy to hear that
pip supports both mechanisms.

One last question: will pip support package extras? The Enthought Tool
Suite (for example) makes extensive use of these, and there are many
projects in our community that build on ETS. A while back there was
some discussion of dropping this feature in pip, which could make it
difficult for some projects to embrace distribute/pip.

Thanks,
Darren

From martin.raspaud at smhi.se  Wed Mar 24 16:35:45 2010
From: martin.raspaud at smhi.se (Martin Raspaud)
Date: Wed, 24 Mar 2010 16:35:45 +0100
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools or zc.buildout
Message-ID: <4BAA3151.6040104@smhi.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I am now working on a project that I need to deploy on different servers in a
compiled form, as tar.gz files (the servers do not have gcc for example).

The project comprises two libraries and an extra set of config files and scripts
for batch computation.

I would like to have a utility that does all the packaging for me, that is
create a tar.gz for each lib and one for the scripts, each containing a
directory with the compiled things.

Here are my different approaches:
- - setuptools bdist: This is almost what I need, except that it creates a usr dir
on top of the tarball.
- - zc.buildout: this looked promissing (although pretty hard to get into). I
stumbled upon collective.releaser, which I thought was what I needed, but its
project_deploy script just tarballs the entire buildout directory.

Here is the config file I used for project_deploy:
[buildout]
parts =
      myproj

[myproj]
recipe=zerokspot.recipe.git
repository=/data/proj/myproj
branch=unstable
as_egg=true

I am getting quite desperate...

Can anyone give me pointers ?

Thanks,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLqjFQAAoJEBdvyODiyJI4Y/cH/0/3osiqHWlzoT4lDiSgnrSu
oG/mQMUHE+kOVHzDaZlf6mEQiTw0Ro2JPOwSSYlmf7dMXxmcCjkvNSmaqf2iYNE6
DN2SfMguIYG7v+hU3y9D9nPCdg4uf0kpxvTOFqm4cGkhnsqnIsy585eW6NLuXiwU
pDuWlkLmYcFgVZGLczEJQ+p0h9ujigrVUZfH1vq+hn1r+Fpa7X69N2EMtBxq/Ull
svqHQrNrEI3Brcv/9T/JMgen3//Mgb4vUrbN81LBa6rOJYth6AK6dBbkp5wicaUn
QnPrl5/im59UJ5IT5Mrbj7o4kYdvKaxM9Iw+5fX4rnp0nV8mlbKv5vastCCJtp0=
=qqAr
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_raspaud.vcf
Type: text/x-vcard
Size: 259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100324/1f8b11ad/attachment-0001.vcf>

From mbaiju at zeomega.com  Wed Mar 24 17:22:23 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Wed, 24 Mar 2010 21:52:23 +0530
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools or
	zc.buildout
In-Reply-To: <4BAA3151.6040104@smhi.se>
References: <4BAA3151.6040104@smhi.se>
Message-ID: <c911c70d1003240922o77b8236ds4c14dcfeb1e0c306@mail.gmail.com>

On Wed, Mar 24, 2010 at 9:05 PM, Martin Raspaud <martin.raspaud at smhi.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> I am now working on a project that I need to deploy on different servers in a
> compiled form, as tar.gz files (the servers do not have gcc for example).
>
> The project comprises two libraries and an extra set of config files and scripts
> for batch computation.
>
> I would like to have a utility that does all the packaging for me, that is
> create a tar.gz for each lib and one for the scripts, each containing a
> directory with the compiled things.
>
> Here are my different approaches:
> - - setuptools bdist: This is almost what I need, except that it creates a usr dir
> on top of the tarball.
> - - zc.buildout: this looked promissing (although pretty hard to get into). I
> stumbled upon collective.releaser, which I thought was what I needed, but its
> project_deploy script just tarballs the entire buildout directory.
>
> Here is the config file I used for project_deploy:
> [buildout]
> parts =
> ? ? ?myproj
>
> [myproj]
> recipe=zerokspot.recipe.git
> repository=/data/proj/myproj
> branch=unstable
> as_egg=true
>
> I am getting quite desperate...
>
> Can anyone give me pointers ?

May be this will be useful:
http://pypi.python.org/pypi/zc.sourcerelease

Regards,
Baiju M

From mbaiju at zeomega.com  Wed Mar 24 17:32:05 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Wed, 24 Mar 2010 22:02:05 +0530
Subject: [Distutils] Buildout documentation
Message-ID: <c911c70d1003240932t648baad9p4d3b3266bb045154@mail.gmail.com>

Hi All,
        I can see many people working with Buildout in this list.
There are nearly 200 packages in PyPI with "Framework :: Buildout"
category: http://pypi.python.org/pypi?:action=browse&c=512
This is really amazing.  But the documentation for Buildout
is not sufficient.  I and few others created http://www.buildout.org
during PyCON 2009.  It would be great, if the users of
Buildout coming forward to maintain that documentation.

Now Buildout is used by Zope,Plone,Django and many
other projects.  May be someone can write an entire
book about Buildout :)

Regards,
Baiju M

From carl at dirtcircle.com  Wed Mar 24 17:39:40 2010
From: carl at dirtcircle.com (Carl Meyer)
Date: Wed, 24 Mar 2010 12:39:40 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
 for 2.7
In-Reply-To: <a08e5f81003240615m3d81148qa35bf14319e4024b@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>	
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>	
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>	
	<94bdd2611003240453l79f7787ft101459a199a64061@mail.gmail.com>	
	<a08e5f81003240458g7afcd6d7pe5b19d22ff14304e@mail.gmail.com>	
	<4BAA01BF.30805@dirtcircle.com>
	<a08e5f81003240615m3d81148qa35bf14319e4024b@mail.gmail.com>
Message-ID: <4BAA404C.2020805@dirtcircle.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Darren Dale wrote:
> Right, I am somewhat familiar with requirements files. I guess I have
> not been keeping up closely enough with pip development recently. Last
> I checked, pip supported dependencies via requirements files (which
> are good for setting up applications in isolated environments) but not
> recursively and not without a requirements file like easy_install does

This was a misunderstanding. Pip has done recursive dependency fetching
based on install_requires metadata for years; at least as long as its
been named pip, AFAIK. Requirements files have always been an optional
feature.

> One last question: will pip support package extras? The Enthought Tool
> Suite (for example) makes extensive use of these, and there are many
> projects in our community that build on ETS. A while back there was
> some discussion of dropping this feature in pip, which could make it
> difficult for some projects to embrace distribute/pip.

Sorry, I don't know anything about the status of extras in pip.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuqQEwACgkQ1j/fhc23WECJ/gCghCGiPgoP3/ZVyU4V7+F25vfA
IL0AnjzufpWl/saNJaZT+aviJBg9HkgB
=fVzB
-----END PGP SIGNATURE-----

From fdrake at acm.org  Wed Mar 24 17:40:09 2010
From: fdrake at acm.org (Fred Drake)
Date: Wed, 24 Mar 2010 12:40:09 -0400
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools or
	zc.buildout
In-Reply-To: <c911c70d1003240922o77b8236ds4c14dcfeb1e0c306@mail.gmail.com>
References: <4BAA3151.6040104@smhi.se>
	<c911c70d1003240922o77b8236ds4c14dcfeb1e0c306@mail.gmail.com>
Message-ID: <9cee7ab81003240940g2faf0f43iaff2215393c06772@mail.gmail.com>

On Wed, Mar 24, 2010 at 12:22 PM, Baiju M <mbaiju at zeomega.com> wrote:
> May be this will be useful:
> http://pypi.python.org/pypi/zc.sourcerelease

It sounds to me like Martin's problem isn't getting source releases,
but in deploying them on systems without compilers and other tools.

What we're doing at Zope Corporation is building source releases
(using zc.sourcerelease as Baiju suggested), and then building
packages that the system package management tools can use from those
source releases.  (In our case the packages are RPMs, but it could be
anything.)

But the zc.sourcerelease releases are a good starting point for that
since the dependency packaging and management is handled for you.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From ziade.tarek at gmail.com  Wed Mar 24 17:47:34 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 24 Mar 2010 17:47:34 +0100
Subject: [Distutils] Buildout documentation
In-Reply-To: <c911c70d1003240932t648baad9p4d3b3266bb045154@mail.gmail.com>
References: <c911c70d1003240932t648baad9p4d3b3266bb045154@mail.gmail.com>
Message-ID: <94bdd2611003240947x21575247sb3ee6875c8f636e0@mail.gmail.com>

On Wed, Mar 24, 2010 at 5:32 PM, Baiju M <mbaiju at zeomega.com> wrote:
> Hi All,
> ? ? ? ?I can see many people working with Buildout in this list.
> There are nearly 200 packages in PyPI with "Framework :: Buildout"
> category: http://pypi.python.org/pypi?:action=browse&c=512
> This is really amazing. ?But the documentation for Buildout
> is not sufficient. ?I and few others created http://www.buildout.org
> during PyCON 2009. ?It would be great, if the users of
> Buildout coming forward to maintain that documentation.
>
> Now Buildout is used by Zope,Plone,Django and many
> other projects. ?May be someone can write an entire
> book about Buildout :)

If you don't mind, I'll add my request too ;)

I am looking for someone that is willing to write a section about
buildout in the Hitchhicker's guide.

A small tutorial that demonstrates its capabilities.

Regards,
Tarek

-- 
Tarek Ziad? | http://ziade.org

From mbaiju at zeomega.com  Wed Mar 24 17:48:04 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Wed, 24 Mar 2010 22:18:04 +0530
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools or
	zc.buildout
In-Reply-To: <9cee7ab81003240940g2faf0f43iaff2215393c06772@mail.gmail.com>
References: <4BAA3151.6040104@smhi.se>
	<c911c70d1003240922o77b8236ds4c14dcfeb1e0c306@mail.gmail.com>
	<9cee7ab81003240940g2faf0f43iaff2215393c06772@mail.gmail.com>
Message-ID: <c911c70d1003240948q2c9ca36cg4bc66555d64745a4@mail.gmail.com>

On Wed, Mar 24, 2010 at 10:10 PM, Fred Drake <fdrake at acm.org> wrote:
> On Wed, Mar 24, 2010 at 12:22 PM, Baiju M <mbaiju at zeomega.com> wrote:
>> May be this will be useful:
>> http://pypi.python.org/pypi/zc.sourcerelease
>
> It sounds to me like Martin's problem isn't getting source releases,
> but in deploying them on systems without compilers and other tools.
>
> What we're doing at Zope Corporation is building source releases
> (using zc.sourcerelease as Baiju suggested), and then building
> packages that the system package management tools can use from those
> source releases. ?(In our case the packages are RPMs, but it could be
> anything.)

Can you give some pointer how you are creating RPMs for
the binary eggs (eg:- zope.interface ) Any tool available ?
These RPMs are for entire buildout or individual eggs ?

Regards,
Baiju M

From mbaiju at zeomega.com  Wed Mar 24 17:57:31 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Wed, 24 Mar 2010 22:27:31 +0530
Subject: [Distutils] Buildout documentation
In-Reply-To: <c911c70d1003240932t648baad9p4d3b3266bb045154@mail.gmail.com>
References: <c911c70d1003240932t648baad9p4d3b3266bb045154@mail.gmail.com>
Message-ID: <c911c70d1003240957w32d1cc95i704833b7c76152f5@mail.gmail.com>

On Wed, Mar 24, 2010 at 10:02 PM, Baiju M <mbaiju at zeomega.com> wrote:
> Hi All,
> ? ? ? ?I can see many people working with Buildout in this list.
> There are nearly 200 packages in PyPI with "Framework :: Buildout"
> category: http://pypi.python.org/pypi?:action=browse&c=512
> This is really amazing. ?But the documentation for Buildout
> is not sufficient. ?I and few others created http://www.buildout.org
> during PyCON 2009. ?It would be great, if the users of
> Buildout coming forward to maintain that documentation.
>
> Now Buildout is used by Zope,Plone,Django and many
> other projects. ?May be someone can write an entire
> book about Buildout :)

BTW, if volunteers are coming forward.  I can coordinate
and provide all details required for updating the documentation.

Regards,
Baiju M

From ianb at colorstudy.com  Wed Mar 24 18:19:27 2010
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 24 Mar 2010 12:19:27 -0500
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com> 
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com> 
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com> 
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
Message-ID: <b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>

On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang <olemis at gmail.com> wrote:
> My experience is that only `install_requires` is needed (unless you
> want to create app bundles AFAICR) , but in practice I've noticed that
> *some* easy_installable packages are not pip-able (though I had no
> time to figure out why :-/ )

Usually this is because Setuptools is poking at objects to do its
work, while pip tries to work mostly with subprocesses.  Though to
complicate things a bit, pip makes sure the Setuptools monkeypatches
to distutils are applied, so that it's always as though the setup.py
says "from setuptools import setup".  easy_install *also* does this.

But then easy_install starts calling methods and whatnot, while pip just does:

  setup.py install --single-version-externally-managed --no-deps
--record some_tmp_file

The --no-deps keeps Setuptools from resolving dependencies (because it
does so using easy_install), and --single-version-externally-managed
keeps Setuptools doing egg directories.  And --record keeps track of
installed files, which are later moved around to facilitate uninstall.
 But some distributions pay extra attention to those options, or do
other tricky things in their setup.py, and as a result this causes
failures.  Because easy_install is just calling internal methods, it
kind of sidelines those tricks (also people don't tend to give these
options to easy_install, and some don't even exist, so some code paths
just aren't exercised with typical easy_install usage).

Oh, the other reason is the link searching mechanism is slightly
different between the two installers.  Not particularly intentionally,
just incidentally.  Also because pip doesn't install anything but
source packages, some packages are installable via easy_install but
not pip -- usually this is an oversight on the part of the person
doing the packaging, but they just never noticed.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://twitter.com/ianbicking

From fdrake at acm.org  Wed Mar 24 18:24:59 2010
From: fdrake at acm.org (Fred Drake)
Date: Wed, 24 Mar 2010 13:24:59 -0400
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools or
	zc.buildout
In-Reply-To: <c911c70d1003240948q2c9ca36cg4bc66555d64745a4@mail.gmail.com>
References: <4BAA3151.6040104@smhi.se>
	<c911c70d1003240922o77b8236ds4c14dcfeb1e0c306@mail.gmail.com> 
	<9cee7ab81003240940g2faf0f43iaff2215393c06772@mail.gmail.com> 
	<c911c70d1003240948q2c9ca36cg4bc66555d64745a4@mail.gmail.com>
Message-ID: <9cee7ab81003241024n2641378fqe3bf0d28faf7ecd@mail.gmail.com>

On Wed, Mar 24, 2010 at 12:48 PM, Baiju M <mbaiju at zeomega.com> wrote:
> Can you give some pointer how you are creating RPMs for
> the binary eggs (eg:- zope.interface ) Any tool available ?

The RPM is built using the normal RPM tools: we write a spec file,
then run rpmbuild in what we think are the normal ways.  Nothing
special is needed.

> These RPMs are for entire buildout or individual eggs ?

For the entire buildout, since they're applications.  We use a
separate package (RPM) with a "clean" Python (nothing in
site-packages!) that won't be affected by general system updates.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From ziade.tarek at gmail.com  Wed Mar 24 18:35:05 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 24 Mar 2010 18:35:05 +0100
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools or
	zc.buildout
In-Reply-To: <9cee7ab81003241024n2641378fqe3bf0d28faf7ecd@mail.gmail.com>
References: <4BAA3151.6040104@smhi.se>
	<c911c70d1003240922o77b8236ds4c14dcfeb1e0c306@mail.gmail.com>
	<9cee7ab81003240940g2faf0f43iaff2215393c06772@mail.gmail.com>
	<c911c70d1003240948q2c9ca36cg4bc66555d64745a4@mail.gmail.com>
	<9cee7ab81003241024n2641378fqe3bf0d28faf7ecd@mail.gmail.com>
Message-ID: <94bdd2611003241035y25cd6981sb73dcc71aad201ca@mail.gmail.com>

On Wed, Mar 24, 2010 at 6:24 PM, Fred Drake <fdrake at acm.org> wrote:
> On Wed, Mar 24, 2010 at 12:48 PM, Baiju M <mbaiju at zeomega.com> wrote:
>> Can you give some pointer how you are creating RPMs for
>> the binary eggs (eg:- zope.interface ) Any tool available ?
>
> The RPM is built using the normal RPM tools: we write a spec file,
> then run rpmbuild in what we think are the normal ways. ?Nothing
> special is needed.
>
>> These RPMs are for entire buildout or individual eggs ?
>
> For the entire buildout, since they're applications. ?We use a
> separate package (RPM) with a "clean" Python (nothing in
> site-packages!) that won't be affected by general system updates.

We use to do the same but we build the isolated buildout using
collective.releaser.

The tool is a script that creates a binary zip containing the built
buildout, that can be re-run
on a similar arch without any web access.

It also has features like patch creation for buildout (will create a
small archive with a patch
to be applied on an existing buildout for upgrades)

I think the tool is still maintained by Ingeniweb but under-documented



>
>
> ?-Fred
>
> --
> Fred L. Drake, Jr. ? ?<fdrake at gmail.com>
> "Chaos is the score upon which reality is written." --Henry Miller
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From dsdale24 at gmail.com  Wed Mar 24 18:53:46 2010
From: dsdale24 at gmail.com (Darren Dale)
Date: Wed, 24 Mar 2010 13:53:46 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
Message-ID: <a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>

On Wed, Mar 24, 2010 at 1:19 PM, Ian Bicking <ianb at colorstudy.com> wrote:
> On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang <olemis at gmail.com> wrote:
>> My experience is that only `install_requires` is needed (unless you
>> want to create app bundles AFAICR) , but in practice I've noticed that
>> *some* easy_installable packages are not pip-able (though I had no
>> time to figure out why :-/ )
>
> Usually this is because Setuptools is poking at objects to do its
> work, while pip tries to work mostly with subprocesses. ?Though to
> complicate things a bit, pip makes sure the Setuptools monkeypatches
> to distutils are applied, so that it's always as though the setup.py
> says "from setuptools import setup". ?easy_install *also* does this.
>
> But then easy_install starts calling methods and whatnot, while pip just does:
>
> ?setup.py install --single-version-externally-managed --no-deps
> --record some_tmp_file
>
> The --no-deps keeps Setuptools from resolving dependencies

Seeking clarification: how can pip recursively install dependencies
*and* keep Setuptools from resolving dependencies?

Darren

From jbaker at zeomega.com  Wed Mar 24 19:06:03 2010
From: jbaker at zeomega.com (Jason Baker)
Date: Wed, 24 Mar 2010 13:06:03 -0500
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
Message-ID: <fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>

On Wed, Mar 24, 2010 at 12:53 PM, Darren Dale <dsdale24 at gmail.com> wrote:

> On Wed, Mar 24, 2010 at 1:19 PM, Ian Bicking <ianb at colorstudy.com> wrote:
> > On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang <olemis at gmail.com> wrote:
> >> My experience is that only `install_requires` is needed (unless you
> >> want to create app bundles AFAICR) , but in practice I've noticed that
> >> *some* easy_installable packages are not pip-able (though I had no
> >> time to figure out why :-/ )
> >
> > Usually this is because Setuptools is poking at objects to do its
> > work, while pip tries to work mostly with subprocesses.  Though to
> > complicate things a bit, pip makes sure the Setuptools monkeypatches
> > to distutils are applied, so that it's always as though the setup.py
> > says "from setuptools import setup".  easy_install *also* does this.
> >
> > But then easy_install starts calling methods and whatnot, while pip just
> does:
> >
> >  setup.py install --single-version-externally-managed --no-deps
> > --record some_tmp_file
> >
> > The --no-deps keeps Setuptools from resolving dependencies
>
> Seeking clarification: how can pip recursively install dependencies
> *and* keep Setuptools from resolving dependencies?
>
>
Using the --no-deps option to setup.py
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100324/2000f593/attachment.html>

From rob at kalistra.com  Wed Mar 24 19:26:05 2010
From: rob at kalistra.com (Rob Miller)
Date: Wed, 24 Mar 2010 11:26:05 -0700
Subject: [Distutils] repeatable and updatable virtualenv
In-Reply-To: <4BA9E617.2060903@simplistix.co.uk>
References: <4B9F40B3.90401@simplistix.co.uk>	<4957f1ef1003190631w52e75c3cmb74796e51759c55a@mail.gmail.com>	<5e5cdb041003190824t47d48091s6bcf6602a3b00ca7@mail.gmail.com>	<4BA73186.8090304@simplistix.co.uk>	<319e029f1003230321q218f9c7ahc02af8603b34dc8c@mail.gmail.com>
	<4BA9E617.2060903@simplistix.co.uk>
Message-ID: <hodlgm$976$1@dough.gmane.org>

Chris Withers wrote:
> Lennart Regebro wrote:
>> On Mon, Mar 22, 2010 at 09:59, Chris Withers <chris at simplistix.co.uk> 
>> wrote:
>>> Saint Germain wrote:
>>>> I'm currently trying more or less the same thing by combining buildout
>>>> with virtualenv and pip.
>>> This doesn't seem like a sane thing to do.
>>
>> Sure it does. It's just not very useful in most cases. Buildout by
>> itself works fine to isolate the python installation from the stuff
>> installed.
> 
> Well, no, using a virtualenv to wrap a buildout is far from insane, 
> especially until Gary's work to make site-packages optionally excluded 
> from the search path lands!
> 
> However, the OP's recommended recipes appear to just use buildout to 
> drive virtualenv, ignoring all of buildout's python package management.
> That seems insane...

I wrote the rjm.recipe.venv recipe.  All it does is turn the buildout root 
directory into a virtualenv, so you can use virtualenv to wrap the buildout 
w/o having to take an extra step, or worry about whether or not one of your 
downstream users has forgotten to do so.

That being said, I also like the idea of gp.recipe.pip.  I'll admit that it 
_is_ a bit insane.  But the pip/virtualenv combination fits my brain better 
than buildout.  I don't much care for zc.recipe.egg, I prefer virtualenv's 
approach of mimicking Python's package management mechanisms, so that I don't 
have to context switch between my sandboxed environments and the way Python 
works at the system level.  gp.recipe.pip is nowhere near as battle-hardened 
as zc.recipe.egg, nor does it support every use case that zc.recipe.egg 
supports, but I can certainly understand the motivation.

-r


From aaron.brice at gmail.com  Wed Mar 24 20:01:48 2010
From: aaron.brice at gmail.com (Aaron Brice)
Date: Wed, 24 Mar 2010 12:01:48 -0700
Subject: [Distutils] bdist_rpm with different python version
Message-ID: <cc3f5e2f1003241201q7f135b4eid254edb9d0b52034@mail.gmail.com>

I am working on a RHEL5 system with python 2.4 installed as
/usr/bin/python and python 2.6 installed as /usr/bin/python2.6.

When I run "python2.6 setup.py install" in a module it generally does
the right thing and installs to /usr/lib/python2.6/site-packages/.  So
I want to generate a rpm to deploy the module, but "python2.6 setup.py
bdist_rpm" does not do the right thing, the .spec file generated uses
"python" and not "python2.6" and the resulting rpm installs to
/usr/lib/python2.4/site-packages/.

Is there a way to override this behavior?

Thanks,
Aaron

From pje at telecommunity.com  Wed Mar 24 20:11:33 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 24 Mar 2010 15:11:33 -0400
Subject: [Distutils] bdist_rpm with different python version
In-Reply-To: <cc3f5e2f1003241201q7f135b4eid254edb9d0b52034@mail.gmail.co
 m>
References: <cc3f5e2f1003241201q7f135b4eid254edb9d0b52034@mail.gmail.com>
Message-ID: <20100324191127.393743A40AF@sparrow.telecommunity.com>

At 12:01 PM 3/24/2010 -0700, Aaron Brice wrote:
>I am working on a RHEL5 system with python 2.4 installed as
>/usr/bin/python and python 2.6 installed as /usr/bin/python2.6.
>
>When I run "python2.6 setup.py install" in a module it generally does
>the right thing and installs to /usr/lib/python2.6/site-packages/.  So
>I want to generate a rpm to deploy the module, but "python2.6 setup.py
>bdist_rpm" does not do the right thing, the .spec file generated uses
>"python" and not "python2.6" and the resulting rpm installs to
>/usr/lib/python2.4/site-packages/.
>
>Is there a way to override this behavior?

The --fix-python option hardcodes the path to the currently-running 
python.  Run "setup.py bdist_rpm --help" for more details.


From pje at telecommunity.com  Wed Mar 24 20:12:05 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 24 Mar 2010 15:12:05 -0400
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools or
 zc.buildout
In-Reply-To: <4BAA3151.6040104@smhi.se>
References: <4BAA3151.6040104@smhi.se>
Message-ID: <20100324191159.4CF973A40AF@sparrow.telecommunity.com>

At 04:35 PM 3/24/2010 +0100, Martin Raspaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hello,
>
>I am now working on a project that I need to deploy on different servers in a
>compiled form, as tar.gz files (the servers do not have gcc for example).
>
>The project comprises two libraries and an extra set of config files 
>and scripts
>for batch computation.
>
>I would like to have a utility that does all the packaging for me, that is
>create a tar.gz for each lib and one for the scripts, each containing a
>directory with the compiled things.
>
>Here are my different approaches:
>- - setuptools bdist: This is almost what I need, except that it 
>creates a usr dir
>on top of the tarball.

You could always repack the tarball without it, or change your 
default installation prefix to match that of the target system(s).

(There's a --relative option, too, but it seems to be broken when I 
try it on my systems.)


From dsdale24 at gmail.com  Wed Mar 24 22:04:58 2010
From: dsdale24 at gmail.com (Darren Dale)
Date: Wed, 24 Mar 2010 17:04:58 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
Message-ID: <a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>

On Wed, Mar 24, 2010 at 2:06 PM, Jason Baker <jbaker at zeomega.com> wrote:
> On Wed, Mar 24, 2010 at 12:53 PM, Darren Dale <dsdale24 at gmail.com> wrote:
>>
>> On Wed, Mar 24, 2010 at 1:19 PM, Ian Bicking <ianb at colorstudy.com> wrote:
>> > On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang <olemis at gmail.com> wrote:
>> >> My experience is that only `install_requires` is needed (unless you
>> >> want to create app bundles AFAICR) , but in practice I've noticed that
>> >> *some* easy_installable packages are not pip-able (though I had no
>> >> time to figure out why :-/ )
>> >
>> > Usually this is because Setuptools is poking at objects to do its
>> > work, while pip tries to work mostly with subprocesses. ?Though to
>> > complicate things a bit, pip makes sure the Setuptools monkeypatches
>> > to distutils are applied, so that it's always as though the setup.py
>> > says "from setuptools import setup". ?easy_install *also* does this.
>> >
>> > But then easy_install starts calling methods and whatnot, while pip just
>> > does:
>> >
>> > ?setup.py install --single-version-externally-managed --no-deps
>> > --record some_tmp_file
>> >
>> > The --no-deps keeps Setuptools from resolving dependencies
>>
>> Seeking clarification: how can pip recursively install dependencies
>> *and* keep Setuptools from resolving dependencies?
>>
>
> Using the --no-deps option to setup.py

Amusing. Seriously though, how does pip determine the dependencies if
it is calling setup.py with arguments that prevent Setuptools from
resolving the dependencies? pip --help doesn't indicate a --no-deps
option, it sounds like pip is passing that option to setup.py under
the hood.

Darren

From sridharr at activestate.com  Wed Mar 24 22:30:15 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 24 Mar 2010 14:30:15 -0700
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
Message-ID: <CFD9EAFF-33C5-4BAE-977B-1E70DFC8283B@activestate.com>


On 2010-03-24, at 2:04 PM, Darren Dale wrote:

>>> Seeking clarification: how can pip recursively install dependencies
>>> *and* keep Setuptools from resolving dependencies?
>>> 
>> 
>> Using the --no-deps option to setup.py
> 
> Amusing. Seriously though, how does pip determine the dependencies if
> it is calling setup.py with arguments that prevent Setuptools from
> resolving the dependencies? pip --help doesn't indicate a --no-deps
> option, it sounds like pip is passing that option to setup.py under
> the hood.


"prevent setuptools from resolving the dependencies" actually means "Hey setutools, just install Foo into site-packages, but don't bother about its dependencies".

Each installed package has a 'requires.txt' file that lists the dependencies of that package. pip presumably uses this file. 

$ cat ~/.local/lib/python2.6/site-packages/pylint-0.19.0-py2.6.egg-info/requires.txt 
logilab-common
logilab-astng >= 0.19.2s
$

-srid


From dsdale24 at gmail.com  Wed Mar 24 22:41:11 2010
From: dsdale24 at gmail.com (Darren Dale)
Date: Wed, 24 Mar 2010 17:41:11 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <CFD9EAFF-33C5-4BAE-977B-1E70DFC8283B@activestate.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<CFD9EAFF-33C5-4BAE-977B-1E70DFC8283B@activestate.com>
Message-ID: <a08e5f81003241441s55b56444m21f1253fbacc2f95@mail.gmail.com>

On Wed, Mar 24, 2010 at 5:30 PM, Sridhar Ratnakumar
<sridharr at activestate.com> wrote:
>
> On 2010-03-24, at 2:04 PM, Darren Dale wrote:
>
>>>> Seeking clarification: how can pip recursively install dependencies
>>>> *and* keep Setuptools from resolving dependencies?
>>>>
>>>
>>> Using the --no-deps option to setup.py
>>
>> Amusing. Seriously though, how does pip determine the dependencies if
>> it is calling setup.py with arguments that prevent Setuptools from
>> resolving the dependencies? pip --help doesn't indicate a --no-deps
>> option, it sounds like pip is passing that option to setup.py under
>> the hood.
>
>
> "prevent setuptools from resolving the dependencies" actually means "Hey setutools, just install Foo into site-packages, but don't bother about its dependencies".
>
> Each installed package has a 'requires.txt' file that lists the dependencies of that package. pip presumably uses this file.
>
> $ cat ~/.local/lib/python2.6/site-packages/pylint-0.19.0-py2.6.egg-info/requires.txt
> logilab-common
> logilab-astng >= 0.19.2s
> $

Ok, I think I understand now. Thanks.

Darren

From carl at dirtcircle.com  Wed Mar 24 22:44:21 2010
From: carl at dirtcircle.com (Carl Meyer)
Date: Wed, 24 Mar 2010 17:44:21 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
 for 2.7
In-Reply-To: <a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
Message-ID: <4BAA87B5.1050605@dirtcircle.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Darren,

Darren Dale wrote:
> Amusing. Seriously though, how does pip determine the dependencies if
> it is calling setup.py with arguments that prevent Setuptools from
> resolving the dependencies? pip --help doesn't indicate a --no-deps
> option, it sounds like pip is passing that option to setup.py under
> the hood.

Pip asks setuptools not to install dependencies because pip has already
handled them. (Pip does some things differently from easy_install; for
instance it downloads all dependencies and runs "setup.py egg_info" on
each before actually installing any of them, to reduce the chances that
a broken dependency leaves your system in an inconsistent state). Pip
only shells out to setuptools for the actual installation of each
individual package, once it has already resolved dependencies and
downloaded all of them.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuqh7UACgkQ1j/fhc23WEASjgCeMd7q515GW1k9evrjrkUeensN
Fz8AoILeDhVJb8AETL9Bq8R0jzBXsBMa
=xzjl
-----END PGP SIGNATURE-----

From ziade.tarek at gmail.com  Wed Mar 24 23:19:25 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 24 Mar 2010 23:19:25 +0100
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <4BAA87B5.1050605@dirtcircle.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<4BAA87B5.1050605@dirtcircle.com>
Message-ID: <94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>

On Wed, Mar 24, 2010 at 10:44 PM, Carl Meyer <carl at dirtcircle.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Darren,
>
> Darren Dale wrote:
>> Amusing. Seriously though, how does pip determine the dependencies if
>> it is calling setup.py with arguments that prevent Setuptools from
>> resolving the dependencies? pip --help doesn't indicate a --no-deps
>> option, it sounds like pip is passing that option to setup.py under
>> the hood.
>
> Pip asks setuptools not to install dependencies because pip has already
> handled them. (Pip does some things differently from easy_install; for
> instance it downloads all dependencies and runs "setup.py egg_info" on
> each before actually installing any of them, to reduce the chances that
> a broken dependency leaves your system in an inconsistent state). Pip
> only shells out to setuptools for the actual installation of each
> individual package, once it has already resolved dependencies and
> downloaded all of them.

BTW, That makes me wonder how hard it would be to make it use a plain
"python setup.py install" call
instead, to remove the easy_install dependency ?  Since it could
simply loop into each dependency

I am thinking about a version of pip that would be built on the top of
distutils2,

>
> Carl
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuqh7UACgkQ1j/fhc23WEASjgCeMd7q515GW1k9evrjrkUeensN
> Fz8AoILeDhVJb8AETL9Bq8R0jzBXsBMa
> =xzjl
> -----END PGP SIGNATURE-----
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From robert.kern at gmail.com  Wed Mar 24 23:27:32 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 24 Mar 2010 17:27:32 -0500
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>	<4BAA87B5.1050605@dirtcircle.com>
	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
Message-ID: <hoe3km$vhh$1@dough.gmane.org>

On 2010-03-24 17:19 PM, Tarek Ziad? wrote:

> BTW, That makes me wonder how hard it would be to make it use a plain
> "python setup.py install" call
> instead, to remove the easy_install dependency ?  Since it could
> simply loop into each dependency

Some packages use setuptools and some don't. Since setuptools changes the 
behavior of the install command to install .eggs, those packages need extra 
flags to use pip's preferred flat installs. Using easy_install (with the right 
flags) yields consistent behavior for all packages.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From ziade.tarek at gmail.com  Wed Mar 24 23:53:00 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 24 Mar 2010 23:53:00 +0100
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <hoe3km$vhh$1@dough.gmane.org>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<4BAA87B5.1050605@dirtcircle.com>
	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
	<hoe3km$vhh$1@dough.gmane.org>
Message-ID: <94bdd2611003241553h32bcdf84qd970351747562611@mail.gmail.com>

On Wed, Mar 24, 2010 at 11:27 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On 2010-03-24 17:19 PM, Tarek Ziad? wrote:
>
>> BTW, That makes me wonder how hard it would be to make it use a plain
>> "python setup.py install" call
>> instead, to remove the easy_install dependency ? ?Since it could
>> simply loop into each dependency
>
> Some packages use setuptools and some don't. Since setuptools changes the
> behavior of the install command to install .eggs, those packages need extra
> flags to use pip's preferred flat installs. Using easy_install (with the
> right flags) yields consistent behavior for all packages.

That's just an environment problem.

Notice that I've never tried it, but this could be done by properly
configuring the default behavior of easy_install globally (with the
distutils.cfg file for instance since its a distutils command) so it
behaves like pip wants when "python setup.py install" is called.

Plus, it would fix the fact that a system that use easy_install *and*
pip may have some problems. For example, when the first one is used to
install a package and the other one to upgrade it, it may not work as
expected.

In any case, calling easy_install via pip to do a flat install with no
deps, basically means that you use a very small
subset of the setuptools or distribute you could technically replace.
Besides a heavy, non-future proof dependency I don't see any benefit.

Tarek
-- 
Tarek Ziad? | http://ziade.org

From robert.kern at gmail.com  Thu Mar 25 00:20:11 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 24 Mar 2010 18:20:11 -0500
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <94bdd2611003241553h32bcdf84qd970351747562611@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>	<4BAA87B5.1050605@dirtcircle.com>	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>	<hoe3km$vhh$1@dough.gmane.org>
	<94bdd2611003241553h32bcdf84qd970351747562611@mail.gmail.com>
Message-ID: <hoe6nd$9ml$1@dough.gmane.org>

On 2010-03-24 17:53 PM, Tarek Ziad? wrote:
> On Wed, Mar 24, 2010 at 11:27 PM, Robert Kern<robert.kern at gmail.com>  wrote:
>> On 2010-03-24 17:19 PM, Tarek Ziad? wrote:
>>
>>> BTW, That makes me wonder how hard it would be to make it use a plain
>>> "python setup.py install" call
>>> instead, to remove the easy_install dependency ?  Since it could
>>> simply loop into each dependency
>>
>> Some packages use setuptools and some don't. Since setuptools changes the
>> behavior of the install command to install .eggs, those packages need extra
>> flags to use pip's preferred flat installs. Using easy_install (with the
>> right flags) yields consistent behavior for all packages.
>
> That's just an environment problem.
>
> Notice that I've never tried it, but this could be done by properly
> configuring the default behavior of easy_install globally (with the
> distutils.cfg file for instance since its a distutils command) so it
> behaves like pip wants when "python setup.py install" is called.

The problem with doing that currently is that distutils complains when it 
receives an option that it doesn't recognize. Packages that do not use 
setuptools will fail if you try to provide setuptools-specific configuration:

$ python setup.py install
running install
error: error in /Users/rkern/.pydistutils.cfg: command 'install' has no such 
option 'single_version_externally_managed'

Making those warnings instead of errors would probably work.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From ziade.tarek at gmail.com  Thu Mar 25 00:30:36 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 25 Mar 2010 00:30:36 +0100
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <hoe6nd$9ml$1@dough.gmane.org>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<4BAA87B5.1050605@dirtcircle.com>
	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
	<hoe3km$vhh$1@dough.gmane.org>
	<94bdd2611003241553h32bcdf84qd970351747562611@mail.gmail.com>
	<hoe6nd$9ml$1@dough.gmane.org>
Message-ID: <94bdd2611003241630u5fd0a7f3rf89778cd3cbee3c@mail.gmail.com>

On Thu, Mar 25, 2010 at 12:20 AM, Robert Kern <robert.kern at gmail.com> wrote:
[??]
> The problem with doing that currently is that distutils complains when it
> receives an option that it doesn't recognize.

No because these are options you pass to easy_install only in your
distutils.cfg file:

  [easy_install]
  foo=bar

  [bdist_rpm]
  baz=1
  ...

> Packages that do not use
> setuptools will fail if you try to provide setuptools-specific
> configuration:
>
> $ python setup.py install
> running install
> error: error in /Users/rkern/.pydistutils.cfg: command 'install' has no such
> option 'single_version_externally_managed'

You need to use [easy_install] in your  .pydistutils.cfg, not [install].

The easy_install command is called internally by the install command
in distribute/setuptools.

Meaning that the options will be read and used transparently.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From robert.kern at gmail.com  Thu Mar 25 00:38:34 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 24 Mar 2010 18:38:34 -0500
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <94bdd2611003241630u5fd0a7f3rf89778cd3cbee3c@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>	<4BAA87B5.1050605@dirtcircle.com>	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>	<hoe3km$vhh$1@dough.gmane.org>	<94bdd2611003241553h32bcdf84qd970351747562611@mail.gmail.com>	<hoe6nd$9ml$1@dough.gmane.org>
	<94bdd2611003241630u5fd0a7f3rf89778cd3cbee3c@mail.gmail.com>
Message-ID: <hoe7pr$cbc$1@dough.gmane.org>

On 2010-03-24 18:30 PM, Tarek Ziad? wrote:
> On Thu, Mar 25, 2010 at 12:20 AM, Robert Kern<robert.kern at gmail.com>  wrote:
> [??]
>> The problem with doing that currently is that distutils complains when it
>> receives an option that it doesn't recognize.
>
> No because these are options you pass to easy_install only in your
> distutils.cfg file:
>
>    [easy_install]
>    foo=bar
>
>    [bdist_rpm]
>    baz=1
>    ...
>
>> Packages that do not use
>> setuptools will fail if you try to provide setuptools-specific
>> configuration:
>>
>> $ python setup.py install
>> running install
>> error: error in /Users/rkern/.pydistutils.cfg: command 'install' has no such
>> option 'single_version_externally_managed'
>
> You need to use [easy_install] in your  .pydistutils.cfg, not [install].
>
> The easy_install command is called internally by the install command
> in distribute/setuptools.

The --single-version-externally-managed and --record options are only on the 
install command, not the easy_install command.

$ cat ~/.pydistutils.cfg
[easy_install]
single-version-externally-managed=True
record=/dev/null

$ python setup.py install
running install
error: error in /Users/rkern/.pydistutils.cfg: command 'easy_install' has no 
such option 'single_version_externally_managed'

Please show me a configuration that you have tested.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From ziade.tarek at gmail.com  Thu Mar 25 00:54:12 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 25 Mar 2010 00:54:12 +0100
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <hoe7pr$cbc$1@dough.gmane.org>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<4BAA87B5.1050605@dirtcircle.com>
	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
	<hoe3km$vhh$1@dough.gmane.org>
	<94bdd2611003241553h32bcdf84qd970351747562611@mail.gmail.com>
	<hoe6nd$9ml$1@dough.gmane.org>
	<94bdd2611003241630u5fd0a7f3rf89778cd3cbee3c@mail.gmail.com>
	<hoe7pr$cbc$1@dough.gmane.org>
Message-ID: <94bdd2611003241654t3536bf04m2bb598aae80f8af5@mail.gmail.com>

On Thu, Mar 25, 2010 at 12:38 AM, Robert Kern <robert.kern at gmail.com> wrote:
[..]
> The --single-version-externally-managed and --record options are only on the
> install command, not the easy_install command.

oops that's right I've forgot about that, I thought they were in
easy_install. So it doesn't work.

[..]
> Please show me a configuration that you have tested.

I didn't tested with these options.

The only other way would be to have an ugly patch on install.run in
pip, but that's getting ugly

-- 
Tarek Ziad? | http://ziade.org

From pje at telecommunity.com  Thu Mar 25 01:56:14 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 24 Mar 2010 20:56:14 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
 for 2.7
In-Reply-To: <hoe3km$vhh$1@dough.gmane.org>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<4BAA87B5.1050605@dirtcircle.com>
	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
	<hoe3km$vhh$1@dough.gmane.org>
Message-ID: <20100325005609.E11B43A40AF@sparrow.telecommunity.com>

At 05:27 PM 3/24/2010 -0500, Robert Kern wrote:
>Since setuptools changes the behavior of the install command to 
>install .eggs, those packages need extra flags to use pip's 
>preferred flat installs. Using easy_install (with the right flags) 
>yields consistent behavior for all packages.

Technically, those flags cause setuptools to *not* use easy_install, 
but rather to use more-or-less plain vanilla distutils 
installation.  I haven't looked at pip's code, but I doubt it's 
relying on easy_install at all.

Heck, apart from maybe needing pkg_resources to do some parsing and 
the like, I'd be surprised if pip needs setuptools at all.  Ian's 
said it doesn't use setuptools.package_index to find the packages, so 
that doesn't leave a whole lot for setuptools to do, except maybe 
generate the .egg-info when you're running on Python <2.5.


From hugodoria at gmail.com  Thu Mar 25 03:04:44 2010
From: hugodoria at gmail.com (Hugo Doria)
Date: Wed, 24 Mar 2010 23:04:44 -0300
Subject: [Distutils] Help to create a setup.py (subdirectories aren't
	working)
Message-ID: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.com>

Hi guys,

I am new to distutils and trying to create a setup.py for a project,
but i am having a problem.

My project has this directory layout:

/
/AUTHORS
/README
/myproject (binary)
/MyProject
/MyProject/modules/
/MyProject/modules/first.py
/MyProject/modules/__init__.py
/MyProject/output/
/MyProject/output/second.py
/MyProject/output/__init__.py
/doc/manpage.1

Here's the setup.py that i did:

from distutils.core import setup

DATAFILES = [('/usr/share/man/man1', ['doc/manpage.1']),
		('/usr/share/doc/myproject',['AUTHORS','COPYING','README','TODO'])]

setup(name='MyProject',
      version='0.1',
      license='GPL2',
      description='Trying distutils,
      author=['Hugo Doria'],
      package_dir={'modules':MyProject/modules', 'output':'MyProject/output'},
      packages=['modules', 'output'],
      scripts=['myproject'],
      data_files=DATAFILES)

When i run setup.py install it does works. But i get this on my system:

/usr//lib/python2.6/site-packages/modules
/usr//lib/python2.6/site-packages/output
/usr//lib/python2.6/site-packages/MyProject

It's a bit strange, is not?

Shouldn't it be something like:

/usr//lib/python2.6/site-packages/MyProject
/usr//lib/python2.6/site-packages/MyProject/output/
/usr//lib/python2.6/site-packages/MyProject/modules/

What am i doing wrong?

Thanks.

-- Hugo

From pje at telecommunity.com  Thu Mar 25 03:37:18 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 24 Mar 2010 22:37:18 -0400
Subject: [Distutils] Help to create a setup.py (subdirectories aren't
 working)
In-Reply-To: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.co
 m>
References: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.com>
Message-ID: <20100325023713.47F3F3A40AF@sparrow.telecommunity.com>

At 11:04 PM 3/24/2010 -0300, Hugo Doria wrote:
>Hi guys,
>
>I am new to distutils and trying to create a setup.py for a project,
>but i am having a problem.
>
>My project has this directory layout:
>
>/
>/AUTHORS
>/README
>/myproject (binary)
>/MyProject
>/MyProject/modules/
>/MyProject/modules/first.py
>/MyProject/modules/__init__.py
>/MyProject/output/
>/MyProject/output/second.py
>/MyProject/output/__init__.py
>/doc/manpage.1
>
>Here's the setup.py that i did:
>
>from distutils.core import setup
>
>DATAFILES = [('/usr/share/man/man1', ['doc/manpage.1']),
> 
>('/usr/share/doc/myproject',['AUTHORS','COPYING','README','TODO'])]
>
>setup(name='MyProject',
>       version='0.1',
>       license='GPL2',
>       description='Trying distutils,
>       author=['Hugo Doria'],
>       package_dir={'modules':MyProject/modules', 
> 'output':'MyProject/output'},
>       packages=['modules', 'output'],
>       scripts=['myproject'],
>       data_files=DATAFILES)
>
>When i run setup.py install it does works. But i get this on my system:
>
>/usr//lib/python2.6/site-packages/modules
>/usr//lib/python2.6/site-packages/output
>/usr//lib/python2.6/site-packages/MyProject
>
>It's a bit strange, is not?

It's exactly what you asked for.  Your setup.py says you have two 
top-level packages called 'modules' and 'output', so that's what you got.


>Shouldn't it be something like:
>
>/usr//lib/python2.6/site-packages/MyProject
>/usr//lib/python2.6/site-packages/MyProject/output/
>/usr//lib/python2.6/site-packages/MyProject/modules/
>
>What am i doing wrong?

You're using a package_dir with more than one entry in it, which is a 
sign that your project's layout is broken.  If you wanted a layout 
like the one you describe here, you need to:

1. Omit the package_dir option altogether
2. set packages = ['MyProject', 'MyProject.output', 'MyProject.modules']
3. Add an __init__.py in the MyProject directory, to make it the parent package



From robert.kern at gmail.com  Thu Mar 25 03:58:42 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 24 Mar 2010 21:58:42 -0500
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <20100325005609.E11B43A40AF@sparrow.telecommunity.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>	<4BAA87B5.1050605@dirtcircle.com>	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>	<hoe3km$vhh$1@dough.gmane.org>
	<20100325005609.E11B43A40AF@sparrow.telecommunity.com>
Message-ID: <hoejhu$9mb$1@dough.gmane.org>

On 2010-03-24 19:56 , P.J. Eby wrote:
> At 05:27 PM 3/24/2010 -0500, Robert Kern wrote:
>> Since setuptools changes the behavior of the install command to
>> install .eggs, those packages need extra flags to use pip's preferred
>> flat installs. Using easy_install (with the right flags) yields
>> consistent behavior for all packages.
>
> Technically, those flags cause setuptools to *not* use easy_install, but
> rather to use more-or-less plain vanilla distutils installation. I
> haven't looked at pip's code, but I doubt it's relying on easy_install
> at all.

It does the 'python -c "import setuptools;execfile(...)" install --flags' trick. 
It uses setuptools to make sure that it can pass the same flags for both 
setuptools-using and non-setuptools-using packages.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From martin.raspaud at smhi.se  Thu Mar 25 08:19:50 2010
From: martin.raspaud at smhi.se (Martin Raspaud)
Date: Thu, 25 Mar 2010 08:19:50 +0100
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools or
	zc.buildout
In-Reply-To: <20100324191159.4CF973A40AF@sparrow.telecommunity.com>
References: <4BAA3151.6040104@smhi.se>
	<20100324191159.4CF973A40AF@sparrow.telecommunity.com>
Message-ID: <4BAB0E96.4090806@smhi.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

P.J. Eby skrev:
> At 04:35 PM 3/24/2010 +0100, Martin Raspaud wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> - - setuptools bdist: This is almost what I need, except that it
>> creates a usr dir
>> on top of the tarball.
>
> You could always repack the tarball without it,

yes, but it would be nice if it was automated.

> or change your default
> installation prefix to match that of the target system(s).

- --prefix and --install-dir do not work with the bdist command.

> (There's a --relative option, too, but it seems to be broken when I try
> it on my systems.)
>

Doesn't work for me either.

Is it supported in distribute ?

Regards,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLqw6WAAoJEBdvyODiyJI4dKYIAKUZxFTbWJTEHB4KJXzgk6Pb
i0setaMUU8xBKs0aOFNWbyWRzXrqDu3ecpWDQ8HUzFwsbO+eo6EJDExuWTxvFvo3
CNj9tvtKKiBRENcwG1dK1NyDRFyIHaxSYaCPpAy6DHpN1BXEnm6pQMeKpXUQVRek
r+XKdc+hdwWyDVo9zo+4zYLrVe5rGf8F4MTYYVTNY49xcI0Jg/y7o0dS1HzkZAs2
D8kaQ8h7/PeuoNKI8e4MCLT8NRQ8VzRfFdySBG5O2foEhlLzKD/pA0epS4p0x8BC
ToP6GE4Uedl9Wa8O92z4zAqQxhzp40UXU0UvRU3jvaY8Je5uKKfjX/HGpmTIhsk=
=wKCU
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_raspaud.vcf
Type: text/x-vcard
Size: 259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100325/b870bfac/attachment.vcf>

From martin.raspaud at smhi.se  Thu Mar 25 08:22:43 2010
From: martin.raspaud at smhi.se (Martin Raspaud)
Date: Thu, 25 Mar 2010 08:22:43 +0100
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools or
	zc.buildout
In-Reply-To: <9cee7ab81003240940g2faf0f43iaff2215393c06772@mail.gmail.com>
References: <4BAA3151.6040104@smhi.se>
	<c911c70d1003240922o77b8236ds4c14dcfeb1e0c306@mail.gmail.com>
	<9cee7ab81003240940g2faf0f43iaff2215393c06772@mail.gmail.com>
Message-ID: <4BAB0F43.7080006@smhi.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fred Drake skrev:
> On Wed, Mar 24, 2010 at 12:22 PM, Baiju M <mbaiju at zeomega.com> wrote:
>> May be this will be useful:
>> http://pypi.python.org/pypi/zc.sourcerelease
> 
> It sounds to me like Martin's problem isn't getting source releases,
> but in deploying them on systems without compilers and other tools.

That is it exactly.
Ideally, the zc recipe I'm looking for would install the egg or develop egg to a
given directory, then tarball this directory.


> What we're doing at Zope Corporation is building source releases
> (using zc.sourcerelease as Baiju suggested), and then building
> packages that the system package management tools can use from those
> source releases.  (In our case the packages are RPMs, but it could be
> anything.)

> But the zc.sourcerelease releases are a good starting point for that
> since the dependency packaging and management is handled for you.

I will check it out.

Thanks !
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLqw9DAAoJEBdvyODiyJI4zYMH/R0pJqDdCnNmqVM/x5z0Xhp0
rueSukCGLl5B8rEs+e32B978g8YNe2mBAFi/Tq+bNmg11Osji+ZYhC36Xyy3LuTK
fwTo+aXUszmOAy8lSEXHpCdfnR2ydxLPCwpkMJIfYUqbxsWubZ2lhFPnZzUUxp8m
68h2eNYtE3mtKFAKne/LQASAr04edLCph+BAhPZWCGZv11wm+7m+vBKTxQIefM8P
7I7N2Ni8J3sRvLj3Sq7Khl4jKanQiRD8/d1fJzRrck0dZxbKi1bpyRFtQhOnfV0B
ZK+yGD/DD4hbYvyx/5pHV7yatTcfCXpidr1ppZj8oMdmBruUUVolFDM5Qv4wIfw=
=SSUg
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_raspaud.vcf
Type: text/x-vcard
Size: 259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100325/e9803970/attachment-0001.vcf>

From martin.raspaud at smhi.se  Thu Mar 25 08:26:12 2010
From: martin.raspaud at smhi.se (Martin Raspaud)
Date: Thu, 25 Mar 2010 08:26:12 +0100
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools
	or	zc.buildout
In-Reply-To: <94bdd2611003241035y25cd6981sb73dcc71aad201ca@mail.gmail.com>
References: <4BAA3151.6040104@smhi.se>	<c911c70d1003240922o77b8236ds4c14dcfeb1e0c306@mail.gmail.com>	<9cee7ab81003240940g2faf0f43iaff2215393c06772@mail.gmail.com>	<c911c70d1003240948q2c9ca36cg4bc66555d64745a4@mail.gmail.com>	<9cee7ab81003241024n2641378fqe3bf0d28faf7ecd@mail.gmail.com>
	<94bdd2611003241035y25cd6981sb73dcc71aad201ca@mail.gmail.com>
Message-ID: <4BAB1014.7050408@smhi.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? skrev:
> On Wed, Mar 24, 2010 at 6:24 PM, Fred Drake <fdrake at acm.org> wrote:
>> On Wed, Mar 24, 2010 at 12:48 PM, Baiju M <mbaiju at zeomega.com> wrote:
>>> Can you give some pointer how you are creating RPMs for
>>> the binary eggs (eg:- zope.interface ) Any tool available ?
>> The RPM is built using the normal RPM tools: we write a spec file,
>> then run rpmbuild in what we think are the normal ways.  Nothing
>> special is needed.
>>
>>> These RPMs are for entire buildout or individual eggs ?
>> For the entire buildout, since they're applications.  We use a
>> separate package (RPM) with a "clean" Python (nothing in
>> site-packages!) that won't be affected by general system updates.
> 
> We use to do the same but we build the isolated buildout using
> collective.releaser.
> 
> The tool is a script that creates a binary zip containing the built
> buildout, that can be re-run
> on a similar arch without any web access.
> 
> It also has features like patch creation for buildout (will create a
> small archive with a patch
> to be applied on an existing buildout for upgrades)
> 
> I think the tool is still maintained by Ingeniweb but under-documented
> 
Indeed, the documentation isn't very clear to me.
Project_deploy seemed to do almost what I wanted, except it was packaging the
buildout with the egg, which is not suitable for our installation.

Is there way to tell it to package just an egg ?

Thanks,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLqxAUAAoJEBdvyODiyJI4DlYIAM4t6y3/d/NEphKqUvAkHJqc
ZnqBm1OJ0jLhDw7ca0pWAxz/IS5XuvVW2TxX1sO45D6Xf+8OjWm+CY5hoOFAdI3K
vQbDEpCRgSCAf+NWTAeB8JKelaoHKRNY0VKeCrZ/YH8EFZi61XHGYBKBbInDhsce
i6fe+B0/P/DVTcFvyQGxr3vz3mi2S9RNQ+SsAuj8Y5U9j3TIuf2uAVl16sRSZdZa
j6aDwDh+3B8U3aXQuL7IYi5jYP6NkkyX4RqjZUn8DMzjqYAevuYoMqcMnkax5hCp
/A+WT9vBcnVnZJIKXEYalgp1QagvxX7NfjPcayVTwhzeJFmzHT0awqmSLbg69bM=
=fx/O
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_raspaud.vcf
Type: text/x-vcard
Size: 259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100325/8caa1399/attachment.vcf>

From ziade.tarek at gmail.com  Thu Mar 25 11:20:41 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 25 Mar 2010 11:20:41 +0100
Subject: [Distutils] PEP 376 Status
Message-ID: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>

Hello,

I've sent a mail after Pycon to request some comments on the work we
have done during Pycon but I had no feedback at all :)

http://mail.python.org/pipermail/distutils-sig/2010-March/015684.html

I realize that this piece of work is quite dense, and hard to follow.

(As a reminder the draft is here:
http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst)

I propose to make it a PEP on its own, and to reduce the scope of PEP
376 to what is contains already. This new PEP will be an extension to
the work done in PEP 376 and will not really interfer : the new piece
of work might add a new file in the egg-info directory, but the rest
of the work is elsewhere. (in sysconfig)

Then I propose to focus on PEP 376, and to go ahead and try to have it
accepted before the first beta of Python 2.7.

So basically, PEP 376 defines a directory containing the metadata of
an installed package, and all information about the files installed.
The goal is to provide some APIs in pkgutil, in order to query what's
installed. In other words, add in Python's stdlib what setuptools
provides with pkg_resources.

So what about starting a new round of comments on this PEP,  keeping
in mind that all the unsolved issues about resource files are being
worked out in the other document ?

There's one thing I would like to comment : Someone at Pycon asked me
why the structure was called "PROJECT_NAME.egg-info". After explaining
to him the historical reasons, I realized that there's no benefits at
all to keep this name:

- we've removed the python version from the name of the directory
- we stated that the new APIs will not recognize the old formats
(setuptools', distutils)
- any existing software that want to use the new format will have to
change its code anyways, and a name change don't really add more work.

So I am proposing to replace "egg" by "pkg". For example:

- docutils-0.5.egg-info/
    PKG-INFO
    RECORD

Becomes:

- docutils-0.5.pkg-info/
    PKG-INFO
    RECORD

I am also proposing to change the name of the file "PKG-INFO" into
"METADATA" to stay consistent, because that's what it is.. :

- docutils-0.5.pkg-info/
    METADATA
    RECORD


With these definitions:

  - pkg-info directory : information about a Python software package
that is installed on the system
    - METADATA file: PEP 345 file about a Python software package that
is installed on the system


Any comment on this ? Or on anything else on PEP 376 ?


Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From fdrake at acm.org  Thu Mar 25 12:00:20 2010
From: fdrake at acm.org (Fred Drake)
Date: Thu, 25 Mar 2010 07:00:20 -0400
Subject: [Distutils] PEP 376 Status
In-Reply-To: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
Message-ID: <9cee7ab81003250400i301ac218q4f0b8ec3e14b59b0@mail.gmail.com>

On Thu, Mar 25, 2010 at 6:20 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> - docutils-0.5.pkg-info/
> ? ?METADATA
> ? ?RECORD

+1  :-)


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From hugodoria at gmail.com  Thu Mar 25 12:15:32 2010
From: hugodoria at gmail.com (Hugo Doria)
Date: Thu, 25 Mar 2010 08:15:32 -0300
Subject: [Distutils] Help to create a setup.py (subdirectories aren't
	working)
In-Reply-To: <20100325023713.47F3F3A40AF@sparrow.telecommunity.com>
References: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.com> 
	<20100325023713.47F3F3A40AF@sparrow.telecommunity.com>
Message-ID: <316fa47b1003250415x4568b51ckba3d855180d815fa@mail.gmail.com>

On Wed, Mar 24, 2010 at 11:37 PM, P.J. Eby <pje at telecommunity.com> wrote:
> You're using a package_dir with more than one entry in it, which is a sign
> that your project's layout is broken. ?If you wanted a layout like the one
> you describe here, you need to:

What would be the best layout for this? How should i reorganize my project?

>
> 1. Omit the package_dir option altogether
> 2. set packages = ['MyProject', 'MyProject.output', 'MyProject.modules']
> 3. Add an __init__.py in the MyProject directory, to make it the parent
> package
>

I will try this.

-- Hugo

From ziade.tarek at gmail.com  Thu Mar 25 12:21:22 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 25 Mar 2010 12:21:22 +0100
Subject: [Distutils] Help to create a setup.py (subdirectories aren't
	working)
In-Reply-To: <316fa47b1003250415x4568b51ckba3d855180d815fa@mail.gmail.com>
References: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.com>
	<20100325023713.47F3F3A40AF@sparrow.telecommunity.com>
	<316fa47b1003250415x4568b51ckba3d855180d815fa@mail.gmail.com>
Message-ID: <94bdd2611003250421q1180e307jc5c112457289c9e6@mail.gmail.com>

On Thu, Mar 25, 2010 at 12:15 PM, Hugo Doria <hugodoria at gmail.com> wrote:
> On Wed, Mar 24, 2010 at 11:37 PM, P.J. Eby <pje at telecommunity.com> wrote:
>> You're using a package_dir with more than one entry in it, which is a sign
>> that your project's layout is broken. ?If you wanted a layout like the one
>> you describe here, you need to:
>
> What would be the best layout for this? How should i reorganize my project?
>

We've tried to document this here with what people usually do :
   http://guide.python-distribute.org/creation.html#directory-layout

Feedback welcome !

>>
>> 1. Omit the package_dir option altogether
>> 2. set packages = ['MyProject', 'MyProject.output', 'MyProject.modules']
>> 3. Add an __init__.py in the MyProject directory, to make it the parent
>> package
>>
>
> I will try this.
>
> -- Hugo
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From hugodoria at gmail.com  Thu Mar 25 12:49:31 2010
From: hugodoria at gmail.com (Hugo Doria)
Date: Thu, 25 Mar 2010 08:49:31 -0300
Subject: [Distutils] Help to create a setup.py (subdirectories aren't
	working)
In-Reply-To: <94bdd2611003250421q1180e307jc5c112457289c9e6@mail.gmail.com>
References: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.com> 
	<20100325023713.47F3F3A40AF@sparrow.telecommunity.com>
	<316fa47b1003250415x4568b51ckba3d855180d815fa@mail.gmail.com> 
	<94bdd2611003250421q1180e307jc5c112457289c9e6@mail.gmail.com>
Message-ID: <316fa47b1003250449x5216416bme797d379f4485c9@mail.gmail.com>

The guide help me a lot. Got it working. Thanks guys. ;-)

-- Hugo

From olemis at gmail.com  Thu Mar 25 12:54:19 2010
From: olemis at gmail.com (Olemis Lang)
Date: Thu, 25 Mar 2010 07:54:19 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<94bdd2611003240326u7712700fh5415125208b5fcbf@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<4BAA87B5.1050605@dirtcircle.com>
	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
Message-ID: <24ea26601003250454o73b468d5ha091ef78a8d03dbf@mail.gmail.com>

On Wed, Mar 24, 2010 at 6:19 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Wed, Mar 24, 2010 at 10:44 PM, Carl Meyer <carl at dirtcircle.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>
[...]
>
> I am thinking about a version of pip that would be built on the top of
> distutils2,
>

AFAICR there's a switch to use distribute instead of easy_install (CMIIW)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
TracRpc: API v2: New API methods and exceptions. JSON protocol
refactored and tested ? -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/2643efa5f6d8/

From martin.raspaud at smhi.se  Thu Mar 25 13:07:58 2010
From: martin.raspaud at smhi.se (Martin Raspaud)
Date: Thu, 25 Mar 2010 13:07:58 +0100
Subject: [Distutils] Help to create a setup.py (subdirectories aren't
 working)
In-Reply-To: <94bdd2611003250421q1180e307jc5c112457289c9e6@mail.gmail.com>
References: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.com>	<20100325023713.47F3F3A40AF@sparrow.telecommunity.com>	<316fa47b1003250415x4568b51ckba3d855180d815fa@mail.gmail.com>
	<94bdd2611003250421q1180e307jc5c112457289c9e6@mail.gmail.com>
Message-ID: <4BAB521E.4090800@smhi.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? skrev:
> On Thu, Mar 25, 2010 at 12:15 PM, Hugo Doria <hugodoria at gmail.com> wrote:
>> On Wed, Mar 24, 2010 at 11:37 PM, P.J. Eby <pje at telecommunity.com> wrote:
>>> You're using a package_dir with more than one entry in it, which is a sign
>>> that your project's layout is broken.  If you wanted a layout like the one
>>> you describe here, you need to:
>> What would be the best layout for this? How should i reorganize my project?
>>
> 
> We've tried to document this here with what people usually do :
>    http://guide.python-distribute.org/creation.html#directory-layout
> 
> Feedback welcome !

Nice guide !

One question though: where should I place configuration files for the package,
and how to handle this in setup.py ?

Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLq1IeAAoJEBdvyODiyJI4XO4H+wfakDZ+PYF0xzjhsdpmmNnn
V+Il6Tw7kx5L3pLSVScNRCufn+JEY9LwTjqiE9+CfDf1moMe+f8ZCO4dNJBJspLV
mOQQnimji2fJDJTcvY6UNDKf10nPmztObLsT0qsZB7GssMp6UYgIyGnEej5NKY0M
SNefpMIYomJSFTZb9qfUKa5etKYegKIIg2GOkQ7p0Vrwayd5FDUClBo9rzw7nu9K
CVjExBuykUGcEaSLmZTg/f9l2RF3xU48Jau3a4qUdJoabC/6bmFGZO6o6b9iz95J
EWkGE67c2RcvyJ0uUynoC+d7RiaVJFymYaH/SlbPZRDOH1emC52FutmuI8reBWo=
=7Ujs
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_raspaud.vcf
Type: text/x-vcard
Size: 259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100325/fcaff217/attachment.vcf>

From ziade.tarek at gmail.com  Thu Mar 25 13:09:43 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 25 Mar 2010 13:09:43 +0100
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <24ea26601003250454o73b468d5ha091ef78a8d03dbf@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<a08e5f81003240450xd30444n194f9ad13163d8c7@mail.gmail.com>
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<4BAA87B5.1050605@dirtcircle.com>
	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
	<24ea26601003250454o73b468d5ha091ef78a8d03dbf@mail.gmail.com>
Message-ID: <94bdd2611003250509r1ff55a9je9f868e9ba0a054c@mail.gmail.com>

On Thu, Mar 25, 2010 at 12:54 PM, Olemis Lang <olemis at gmail.com> wrote:
> On Wed, Mar 24, 2010 at 6:19 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Wed, Mar 24, 2010 at 10:44 PM, Carl Meyer <carl at dirtcircle.com> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>
> [...]
>>
>> I am thinking about a version of pip that would be built on the top of
>> distutils2,
>>
>
> AFAICR there's a switch to use distribute instead of easy_install (CMIIW)
>

I apologize, I know it's hard to follow.  Basically what happens is
that our roadmap and work gets refocused at the language summit. It's
for the best results possible, but the caveat is that it's harder to
follow what's going on.

So:

Distribute is a fork of Setuptools  (compatible with it) and last year
we started to work on a new version of it, that would contain all the
new design work. Distribute has also an easy_install script.

What happened then is that we decided during the summit to freeze
distutils in the stdlib, and work outside of the stdlib for a while,
with no backward compat' headaches. This is also to keep a good
stability in the fragile packaging eco-system for Python 2.7 and 3.2 :
everytime I change a line (any line) in distutils, a penguin dies.
(and a project somewhere might break).

So the new work is happening now in a project called "distutils2"
which is using distutils as a basis. The improvements made in
distribute (like py3 support) will be moved to distutils2, and all
PEPs we've recently accepted are implemented there too. One of the PEP
adds all major setuptools innovations, like the requirements at the
project level.

And that makes distutils2 a target for the pip installer.

Summary of the state :
http://guide.python-distribute.org/introduction.html#current-state-of-packaging

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From olemis at gmail.com  Thu Mar 25 13:16:57 2010
From: olemis at gmail.com (Olemis Lang)
Date: Thu, 25 Mar 2010 08:16:57 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <94bdd2611003250509r1ff55a9je9f868e9ba0a054c@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<24ea26601003240527t33c038b2ka1b865dcca172374@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<4BAA87B5.1050605@dirtcircle.com>
	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
	<24ea26601003250454o73b468d5ha091ef78a8d03dbf@mail.gmail.com>
	<94bdd2611003250509r1ff55a9je9f868e9ba0a054c@mail.gmail.com>
Message-ID: <24ea26601003250516i350d625duddc78e72c999a088@mail.gmail.com>

On Thu, Mar 25, 2010 at 8:09 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Thu, Mar 25, 2010 at 12:54 PM, Olemis Lang <olemis at gmail.com> wrote:
>> On Wed, Mar 24, 2010 at 6:19 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>> On Wed, Mar 24, 2010 at 10:44 PM, Carl Meyer <carl at dirtcircle.com> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>
>> [...]
>>>
>>> I am thinking about a version of pip that would be built on the top of
>>> distutils2,
>>>
>>
>> AFAICR there's a switch to use distribute instead of easy_install (CMIIW)
>>
>
> I apologize, I know it's hard to follow.
>
[...]
>
> So the new work is happening now in a project called "distutils2"
> which is using distutils as a basis. The improvements made in
> distribute (like py3 support) will be moved to distutils2, and all
> PEPs we've recently accepted are implemented there too.

What makes me think if `pip` has considered `distribute` then why not
consider `distutils2` as well ? In the end ?The improvements made in
distribute [...] will be moved to distutils2, ?

;o)

> And that makes distutils2 a target for the pip installer.

;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
TracRpc: API v2: New API methods and exceptions. JSON protocol
refactored and tested ? -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/2643efa5f6d8/

From ziade.tarek at gmail.com  Thu Mar 25 13:20:30 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 25 Mar 2010 13:20:30 +0100
Subject: [Distutils] Help to create a setup.py (subdirectories aren't
	working)
In-Reply-To: <4BAB521E.4090800@smhi.se>
References: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.com>
	<20100325023713.47F3F3A40AF@sparrow.telecommunity.com>
	<316fa47b1003250415x4568b51ckba3d855180d815fa@mail.gmail.com>
	<94bdd2611003250421q1180e307jc5c112457289c9e6@mail.gmail.com>
	<4BAB521E.4090800@smhi.se>
Message-ID: <94bdd2611003250520u7f3ae9br1f8b61fc364445e0@mail.gmail.com>

On Thu, Mar 25, 2010 at 1:07 PM, Martin Raspaud <martin.raspaud at smhi.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? skrev:
>> On Thu, Mar 25, 2010 at 12:15 PM, Hugo Doria <hugodoria at gmail.com> wrote:
>>> On Wed, Mar 24, 2010 at 11:37 PM, P.J. Eby <pje at telecommunity.com> wrote:
>>>> You're using a package_dir with more than one entry in it, which is a sign
>>>> that your project's layout is broken. ?If you wanted a layout like the one
>>>> you describe here, you need to:
>>> What would be the best layout for this? How should i reorganize my project?
>>>
>>
>> We've tried to document this here with what people usually do :
>> ? ?http://guide.python-distribute.org/creation.html#directory-layout
>>
>> Feedback welcome !
>
> Nice guide !

Thanks !   HTH

>
> One question though: where should I place configuration files for the package,
> and how to handle this in setup.py ?

There's no good way to do it, the way we handle these files in
distutils is inefficient,
but we are working on this for distutils2.

Today what you can do (that's what I do but maybe others have a better
way to handle this):

  It depends if you are targeting all platforms or just linux. For all
platforms, I would put it *inside* the package
  so I can get it back using the  __file__ variable, no matter if the
package is installed or in development.

  That doesn't work with setuptools or distribute and zipped eggs, but
setuptools has some APIs to do it (so you can get
  the resource file from the zip) -- I expect PJE to give you more
details on this if he sees the mail.

  For linux-only, I install it in /etc, via data_file
  (see http://docs.python.org/distutils/setupscript.html#installing-additional-files),
then I look for the file in the code in
  that place, with a local fallback.


btw, you can probably add an issue here for the guide about it:
http://bitbucket.org/tarek/hitchhiker-guide-packaging/issues/

so we can add a section in the guide about this issue.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From martin.raspaud at smhi.se  Thu Mar 25 13:33:31 2010
From: martin.raspaud at smhi.se (Martin Raspaud)
Date: Thu, 25 Mar 2010 13:33:31 +0100
Subject: [Distutils] Help to create a setup.py (subdirectories aren't
 working)
In-Reply-To: <94bdd2611003250520u7f3ae9br1f8b61fc364445e0@mail.gmail.com>
References: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.com>	
	<20100325023713.47F3F3A40AF@sparrow.telecommunity.com>	
	<316fa47b1003250415x4568b51ckba3d855180d815fa@mail.gmail.com>	
	<94bdd2611003250421q1180e307jc5c112457289c9e6@mail.gmail.com>	
	<4BAB521E.4090800@smhi.se>
	<94bdd2611003250520u7f3ae9br1f8b61fc364445e0@mail.gmail.com>
Message-ID: <4BAB581B.7090001@smhi.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? skrev:

>> One question though: where should I place configuration files for the package,
>> and how to handle this in setup.py ?
> 
> There's no good way to do it, the way we handle these files in
> distutils is inefficient,
> but we are working on this for distutils2.
> 
> Today what you can do (that's what I do but maybe others have a better
> way to handle this):
> 
>   It depends if you are targeting all platforms or just linux. For all
> platforms, I would put it *inside* the package
>   so I can get it back using the  __file__ variable, no matter if the
> package is installed or in development.
> 
>   That doesn't work with setuptools or distribute and zipped eggs, but
> setuptools has some APIs to do it (so you can get
>   the resource file from the zip) -- I expect PJE to give you more
> details on this if he sees the mail.
> 
>   For linux-only, I install it in /etc, via data_file
>   (see http://docs.python.org/distutils/setupscript.html#installing-additional-files),
> then I look for the file in the code in
>   that place, with a local fallback.

Thanks, I think I will go for the local version. It seems to be what setuptools
does anyway.

> btw, you can probably add an issue here for the guide about it:
> http://bitbucket.org/tarek/hitchhiker-guide-packaging/issues/
> 
> so we can add a section in the guide about this issue.

Done.

Regards,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLq1gbAAoJEBdvyODiyJI4ShQIAI4KbxpJnowZT7JHaYIHOzzf
aZZ670yUxet4alcwqIgLkVVq2UAsXubfeiJvgq96pn1Fo7ern4hLI9UR4zODNmYg
vqncpGkl9vk1dDZUgtiUpECLaEayqgQv6xDH2m9vbxlCybfbB4YXDeEFUQWz/GKN
xcgz45HYaBVX4v1yoeE+2pz+scZg2TW5jKTDN4PWgA72JicXOJP/wK7BI6ew0tcH
a1BEIGSYYJsNktnC6r0d3BVWeD4amE7sDfp9RgWNCuYjLIiz62fp7lwz9zTwywJ5
m5HbB7t7HcMAhTdyXohD9ky+68JC67Qi0UL7nTPhv4MVzNebM0lr1/7UqaAjl74=
=G2zk
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_raspaud.vcf
Type: text/x-vcard
Size: 259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100325/fba12eb5/attachment.vcf>

From reinout at vanrees.org  Thu Mar 25 16:30:49 2010
From: reinout at vanrees.org (Reinout van Rees)
Date: Thu, 25 Mar 2010 16:30:49 +0100
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools or
	zc.buildout
In-Reply-To: <9cee7ab81003240940g2faf0f43iaff2215393c06772@mail.gmail.com>
References: <4BAA3151.6040104@smhi.se>	<c911c70d1003240922o77b8236ds4c14dcfeb1e0c306@mail.gmail.com>
	<9cee7ab81003240940g2faf0f43iaff2215393c06772@mail.gmail.com>
Message-ID: <hofvja$mg8$1@dough.gmane.org>

On 03/24/2010 05:40 PM, Fred Drake wrote:
> On Wed, Mar 24, 2010 at 12:22 PM, Baiju M<mbaiju at zeomega.com>  wrote:
>> May be this will be useful:
>> http://pypi.python.org/pypi/zc.sourcerelease
>
> It sounds to me like Martin's problem isn't getting source releases,
> but in deploying them on systems without compilers and other tools.
>
> What we're doing at Zope Corporation is building source releases
> (using zc.sourcerelease as Baiju suggested),

zc.sourcerelease works fine.  I've got one thing I need to fix in it: 
distribute support.  I've got distribute installed globally and 
zc.sourcerelease has 'setuptools' hardcoded.  Corner case.

I'll probably make a branch for it, ok?

> and then building
> packages that the system package management tools can use from those
> source releases.  (In our case the packages are RPMs, but it could be
> anything.)

I experimented this week to create debian packages with 
zc.sourcerelease.  Fun!  I didn't finish it yet, though.  There was one 
question that I couldn't figure out yet:

*How do you get buildout to build in a subdirectory?*  I mean, you can 
give gnu's autoconf mechanism a base prefix argument so that everything 
gets installed into /where/I/build/usr/lib/something instead of 
/usr/lib/something.

If I run buildout, it uses absolute directories, so /where/I/build/ will 
still be in the paths.  My "solution" would be to use debian to get the 
big .tgz into the target dir and then to run "python install.py" in a 
post-install hook or so.

But... I'm probably missing something.  As you're making RPMs you 
probably have a solution ready :-)



Reinout


-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Programmer at http://www.nelen-schuurmans.nl
"Military engineers build missiles. Civil engineers build targets"


From jjposner at optimum.net  Thu Mar 25 16:05:46 2010
From: jjposner at optimum.net (John Posner)
Date: Thu, 25 Mar 2010 11:05:46 -0400
Subject: [Distutils] PEP 376 Status
In-Reply-To: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
Message-ID: <4BAB7BCA.2090604@optimum.net>

On 3/25/2010 6:20 AM, Tarek Ziad? wrote:

<snip>

> So I am proposing to replace "egg" by "pkg". For example:
>
> - docutils-0.5.egg-info/
>      PKG-INFO
>      RECORD
>
> Becomes:
>
> - docutils-0.5.pkg-info/
>      PKG-INFO
>      RECORD
>    

Given issue #8 
(http://bitbucket.org/tarek/hitchhiker-guide-packaging/issue/8/confusing-use-of-term-package-in-package-index), 
might this be a more accurate renaming?

  docutils-0.5.dist-info/
     DIST-INFO
     RECORD

-John


From fdrake at acm.org  Thu Mar 25 16:58:10 2010
From: fdrake at acm.org (Fred Drake)
Date: Thu, 25 Mar 2010 11:58:10 -0400
Subject: [Distutils] Releasing eggs as .tar.gz with setuptools or
	zc.buildout
In-Reply-To: <hofvja$mg8$1@dough.gmane.org>
References: <4BAA3151.6040104@smhi.se>
	<c911c70d1003240922o77b8236ds4c14dcfeb1e0c306@mail.gmail.com> 
	<9cee7ab81003240940g2faf0f43iaff2215393c06772@mail.gmail.com> 
	<hofvja$mg8$1@dough.gmane.org>
Message-ID: <9cee7ab81003250858p2872b302jabff596a4a60f63f@mail.gmail.com>

On Thu, Mar 25, 2010 at 11:30 AM, Reinout van Rees <reinout at vanrees.org> wrote:
> I'll probably make a branch for it, ok?

Sounds good.

> *How do you get buildout to build in a subdirectory?* ?I mean, you can give
> gnu's autoconf mechanism a base prefix argument so that everything gets
> installed into /where/I/build/usr/lib/something instead of
> /usr/lib/something.

There's an option to get buildout to use relative paths; you'll need
to dig that out of the docs and use that.

Some recipes may not support that since it's (relatively) recent.
(Sometime in the past year, maybe?)

> If I run buildout, it uses absolute directories, so /where/I/build/ will
> still be in the paths. ?My "solution" would be to use debian to get the big
> .tgz into the target dir and then to run "python install.py" in a
> post-install hook or so.

We're making RPMs, but I'll bet not all of them are relocatable.  I
know we're using the relative paths bit in some to make things better.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From pje at telecommunity.com  Thu Mar 25 17:35:56 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 25 Mar 2010 12:35:56 -0400
Subject: [Distutils] PEP 376 Status
In-Reply-To: <4BAB7BCA.2090604@optimum.net>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<4BAB7BCA.2090604@optimum.net>
Message-ID: <20100325163551.127F43A4080@sparrow.telecommunity.com>

At 11:05 AM 3/25/2010 -0400, John Posner wrote:
>Given issue #8 
>(http://bitbucket.org/tarek/hitchhiker-guide-packaging/issue/8/confusing-use-of-term-package-in-package-index), 
>might this be a more accurate renaming?
>
>  docutils-0.5.dist-info/
>     DIST-INFO
>     RECORD

+1 (though DIST-INFO could be METADATA)


From ziade.tarek at gmail.com  Thu Mar 25 18:21:17 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 25 Mar 2010 18:21:17 +0100
Subject: [Distutils] PEP 376 Status
In-Reply-To: <20100325163551.127F43A4080@sparrow.telecommunity.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<4BAB7BCA.2090604@optimum.net>
	<20100325163551.127F43A4080@sparrow.telecommunity.com>
Message-ID: <94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>

2010/3/25 P.J. Eby <pje at telecommunity.com>:
> At 11:05 AM 3/25/2010 -0400, John Posner wrote:
>>
>> Given issue #8
>> (http://bitbucket.org/tarek/hitchhiker-guide-packaging/issue/8/confusing-use-of-term-package-in-package-index),
>> might this be a more accurate renaming?
>>
>> ?docutils-0.5.dist-info/
>> ? ?DIST-INFO
>> ? ?RECORD
>
> +1 (though DIST-INFO could be METADATA)
>

Yes so :

docutils-0.5.dist-info/
   METADATA
   RECORD

Sounds reasonable


-- 
Tarek Ziad? | http://ziade.org

From sridharr at activestate.com  Thu Mar 25 19:56:59 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Thu, 25 Mar 2010 11:56:59 -0700
Subject: [Distutils] PEP 376 Status
In-Reply-To: <94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<4BAB7BCA.2090604@optimum.net>
	<20100325163551.127F43A4080@sparrow.telecommunity.com>
	<94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>
Message-ID: <887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>


On 2010-03-25, at 10:21 AM, Tarek Ziad? wrote:

> 2010/3/25 P.J. Eby <pje at telecommunity.com>:
>> At 11:05 AM 3/25/2010 -0400, John Posner wrote:
>>> 
>>> Given issue #8
>>> (http://bitbucket.org/tarek/hitchhiker-guide-packaging/issue/8/confusing-use-of-term-package-in-package-index),
>>> might this be a more accurate renaming?
>>> 
>>>  docutils-0.5.dist-info/
>>>    DIST-INFO
>>>    RECORD
>> 
>> +1 (though DIST-INFO could be METADATA)
>> 
> 
> Yes so :
> 
> docutils-0.5.dist-info/
>   METADATA
>   RECORD

+1

I presume sdist too, if generated with 'python setup.py sdist', will contain this .dist-info directory?

-srid

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100325/ed2358c5/attachment.html>

From jjposner at optimum.net  Thu Mar 25 20:54:49 2010
From: jjposner at optimum.net (John Posner)
Date: Thu, 25 Mar 2010 15:54:49 -0400
Subject: [Distutils] Help to create a setup.py (subdirectories aren't
 working)
In-Reply-To: <94bdd2611003250421q1180e307jc5c112457289c9e6@mail.gmail.com>
References: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.com>
	<20100325023713.47F3F3A40AF@sparrow.telecommunity.com>
	<316fa47b1003250415x4568b51ckba3d855180d815fa@mail.gmail.com>
	<94bdd2611003250421q1180e307jc5c112457289c9e6@mail.gmail.com>
Message-ID: <4BABBF89.90004@optimum.net>

On 3/25/2010 7:21 AM, Tarek Ziad? wrote:

I'm a packaging newbie, but a long-time Python hobbyist programmer and a 
longer-time tech writer. I'm planning to help with the cleanup of the 
Hitchhiker's Guide.

>
>>> 1. Omit the package_dir option altogether
>>> 2. set packages = ['MyProject', 'MyProject.output', 'MyProject.modules']
>>> 3. Add an __init__.py in the MyProject directory, to make it the parent
>>> package
>>>
>>>        

All of the above works for me, and now I'm proceeding to include PNG 
image files in my project. Here's the project's directory structure:

   setup.py

   hibye
   hibye\__init__.py
   hibye\goodbye.py
   hibye\hello.py
   hibye\png
   hibye\png\left_arrow.png
   hibye\png\right_arrow.png

   hibye\french
   hibye\french\__init__.py
   hibye\french\aurevoir.py
   hibye\french\bonjour.py
   hibye\french\french.jpg


And here's my setup.py:

   from setuptools import setup
   ###from distutils.core import setup
   ###import distribute_setup; distribute_setup.use_setuptools()

   setup(name = "hibye",
         version = "6.7",
         packages = ["hibye", "hibye.french"],
         package_data = {
             "hibye": ['png/left_arrow.png', 'png/right_arrow.png'],
             "hibye.french": ['french.jpg'],
         },
   )

With this setup, it seems that "python setup.py bdist_egg" includes the 
PNG files in the distribution, but "python setup.py sdist" does not. I 
need to include a MANIFEST file to have the PNG files included in a 
source distribution. Is that the correct functionality? If so, why the 
difference?

Note: I'm doing my testing inside a virtualenv, on Win/XP SP3.

Tx,
John


From pje at telecommunity.com  Thu Mar 25 21:34:14 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 25 Mar 2010 16:34:14 -0400
Subject: [Distutils] Help to create a setup.py (subdirectories aren't
 working)
In-Reply-To: <4BABBF89.90004@optimum.net>
References: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.com>
	<20100325023713.47F3F3A40AF@sparrow.telecommunity.com>
	<316fa47b1003250415x4568b51ckba3d855180d815fa@mail.gmail.com>
	<94bdd2611003250421q1180e307jc5c112457289c9e6@mail.gmail.com>
	<4BABBF89.90004@optimum.net>
Message-ID: <20100325203409.26B8E3A4080@sparrow.telecommunity.com>

At 03:54 PM 3/25/2010 -0400, John Posner wrote:
>On 3/25/2010 7:21 AM, Tarek Ziad? wrote:
>
>I'm a packaging newbie, but a long-time Python hobbyist programmer 
>and a longer-time tech writer. I'm planning to help with the cleanup 
>of the Hitchhiker's Guide.
>
>>
>>>>1. Omit the package_dir option altogether
>>>>2. set packages = ['MyProject', 'MyProject.output', 'MyProject.modules']
>>>>3. Add an __init__.py in the MyProject directory, to make it the parent
>>>>package
>>>>
>>>>
>
>All of the above works for me, and now I'm proceeding to include PNG 
>image files in my project. Here's the project's directory structure:
>
>   setup.py
>
>   hibye
>   hibye\__init__.py
>   hibye\goodbye.py
>   hibye\hello.py
>   hibye\png
>   hibye\png\left_arrow.png
>   hibye\png\right_arrow.png
>
>   hibye\french
>   hibye\french\__init__.py
>   hibye\french\aurevoir.py
>   hibye\french\bonjour.py
>   hibye\french\french.jpg
>
>
>And here's my setup.py:
>
>   from setuptools import setup
>   ###from distutils.core import setup
>   ###import distribute_setup; distribute_setup.use_setuptools()
>
>   setup(name = "hibye",
>         version = "6.7",
>         packages = ["hibye", "hibye.french"],
>         package_data = {
>             "hibye": ['png/left_arrow.png', 'png/right_arrow.png'],
>             "hibye.french": ['french.jpg'],
>         },
>   )
>
>With this setup, it seems that "python setup.py bdist_egg" includes 
>the PNG files in the distribution, but "python setup.py sdist" does 
>not. I need to include a MANIFEST file to have the PNG files 
>included in a source distribution.

Or, you can place the files under revision control.  CVS and SVN are 
supported natively by setuptools, other systems are supported via 
plugins.  (Note: the recipient of your source distribution will not 
require these tools; setuptools bundles a SOURCES manifest in the 
distribution so the revision control information isn't needed by the 
recipient.)

If your files are under revision control, you also have the option of 
replacing your package_data list with an include_package_data = True flag.


>  Is that the correct functionality? If so, why the difference?

The difference is that in the original design of distutils, including 
arbitrary files in your source distribution is kind of an 
afterthought, whereas in setuptools, the assumption is that your 
source distribution should contain everything you have under revision 
control (or your MANIFEST if you don't have revision control).  Then, 
you can simply tell setuptools to include_package_data, and get your 
data list as a side effect.

Historically, package_data was introduce in setuptools first, then 
adopted by distutils, but this took place before the revision control 
support was added.  Once it was added, it made more sense to treat 
the source distribution as primary...  and hopefully this approach 
will be carried over to distutils2, as well, because there's no need 
to duplicate that info.

Essentially, if you want a DRY (repetition-free) setup, use either 
MANIFEST.in or the revision control system to specify your package 
data files, and then just use include_package_data=True in the 
setup().  (From at least setuptools' POV, package_data is a "legacy" 
feature, rather than a recommended one.)


From jjposner at optimum.net  Thu Mar 25 21:59:09 2010
From: jjposner at optimum.net (John Posner)
Date: Thu, 25 Mar 2010 16:59:09 -0400
Subject: [Distutils] Help to create a setup.py (subdirectories aren't
 working)
In-Reply-To: <20100325203409.26B8E3A4080@sparrow.telecommunity.com>
References: <316fa47b1003241904j3670b64en63a1f7e73a5e34c4@mail.gmail.com>
	<20100325023713.47F3F3A40AF@sparrow.telecommunity.com>
	<316fa47b1003250415x4568b51ckba3d855180d815fa@mail.gmail.com>
	<94bdd2611003250421q1180e307jc5c112457289c9e6@mail.gmail.com>
	<4BABBF89.90004@optimum.net>
	<20100325203409.26B8E3A4080@sparrow.telecommunity.com>
Message-ID: <4BABCE9D.5020904@optimum.net>

On 3/25/2010 4:34 PM, P.J. Eby wrote:
> <snip>
> Essentially, if you want a DRY (repetition-free) setup, use either 
> MANIFEST.in or the revision control system to specify your package 
> data files, and then just use include_package_data=True in the 
> setup().  (From at least setuptools' POV, package_data is a "legacy" 
> feature, rather than a recommended one.)
>
>

Thanks for the very helpful explanation!

-John


From mbaiju at zeomega.com  Fri Mar 26 07:30:39 2010
From: mbaiju at zeomega.com (Baiju M)
Date: Fri, 26 Mar 2010 12:00:39 +0530
Subject: [Distutils] Buildout documentation
In-Reply-To: <c911c70d1003240957w32d1cc95i704833b7c76152f5@mail.gmail.com>
References: <c911c70d1003240932t648baad9p4d3b3266bb045154@mail.gmail.com>
	<c911c70d1003240957w32d1cc95i704833b7c76152f5@mail.gmail.com>
Message-ID: <c911c70d1003252330x7f14bfadrfa335194393e5e8b@mail.gmail.com>

On Wed, Mar 24, 2010 at 10:27 PM, Baiju M <mbaiju at zeomega.com> wrote:
> On Wed, Mar 24, 2010 at 10:02 PM, Baiju M <mbaiju at zeomega.com> wrote:
>> Hi All,
>> ? ? ? ?I can see many people working with Buildout in this list.
>> There are nearly 200 packages in PyPI with "Framework :: Buildout"
>> category: http://pypi.python.org/pypi?:action=browse&c=512
>> This is really amazing. ?But the documentation for Buildout
>> is not sufficient. ?I and few others created http://www.buildout.org
>> during PyCON 2009. ?It would be great, if the users of
>> Buildout coming forward to maintain that documentation.
>>
>> Now Buildout is used by Zope,Plone,Django and many
>> other projects. ?May be someone can write an entire
>> book about Buildout :)
>
> BTW, if volunteers are coming forward. ?I can coordinate
> and provide all details required for updating the documentation.

I have created a wiki to document Buildout:
http://wiki.zope.org/buildout/BuildoutWiki

We will move documentation to official site as it becomes matured.
Let's see how it works.

The format of wiki is reStructuredText so it would be easy to move
to Sphinx. To create a wiki link, you can use two square brackets:

  [[New Link]]


Regards,
Baiju M

From zubin.mithra at gmail.com  Fri Mar 26 08:18:38 2010
From: zubin.mithra at gmail.com (Zubin Mithra)
Date: Fri, 26 Mar 2010 12:48:38 +0530
Subject: [Distutils] log.py->logging ; trac for distutils2
Message-ID: <8e7c74321003260018w1bbe79a7ic0ffdf425b1f8dcb@mail.gmail.com>

Hi,

While going through the distutils code base i realized that logging
was performed with a "log.py" module similar to the logging module in
stdlib.

Apparently, it documented that the idea was to replace the current
system using the "logging" module at some point, but it seems that it
has`nt been done. I`ve made the necessary modifications and will
upload to bitbucket tomorrow.

I`ll also do the same for distutils so that maybe, its a backport for distutils?

I had found that this was a pending task by looking through the
code-base; and the task was quite trivial. I feel that it would be
great if distutils2 had a "trac" of some sort where we could have
tickets related to it.

As distutils2 is not part of the python stdlib as of now, it would be
inappropriate to have those tickets at bugs.python.org , i presume.

Awaiting feedback,
-- 
Zubin Mithra

http://zubin71.wordpress.com

From lacrima.maxim at gmail.com  Fri Mar 26 08:21:59 2010
From: lacrima.maxim at gmail.com (=?UTF-8?B?0JzQsNC60YHQuNC8IExhY3JpbWE=?=)
Date: Fri, 26 Mar 2010 09:21:59 +0200
Subject: [Distutils] How to use Nose plugins with buildout
	pbp.recipe.noserunner recipe ?
In-Reply-To: <5bb76e241003230515u7e7e10efp777be51bf8ba67bf@mail.gmail.com>
References: <5bb76e241003230515u7e7e10efp777be51bf8ba67bf@mail.gmail.com>
Message-ID: <5bb76e241003260021v18938dcdnf520c75a9f4d5bd8@mail.gmail.com>

Hello!

In order if someone is interested how to use Nose plugins with buildout I
have solved this problem in the following way (without noserunner recipe).
[enable_plugin]
recipe = zc.recipe.egg
eggs = nose
       nosegae
       package_under_test
initialization = from nosegae import NoseGAE
arguments = addplugins=[NoseGAE()]
extra-paths = ./parts/google_appengine
              ./parts/google_appengine/lib/yaml/lib


This works for nosegae plugin, though I don't know if the same approach
works for other plugins.

On 23 March 2010 14:15, ?????? Lacrima <lacrima.maxim at gmail.com> wrote:

> Hello!
>
> I've been using buildout. How can I install nose script with
> pbp.recipe.noserunner recipe (or anything else), so that I can pass an
> option to the script to enable plugin?
> Specifically, I want to enable nose plugin for GAE: bin/nose --with-gae.
>
> Thanks in advance.
> Sorry, if my English isn't proper.
>
> with regards,
> Maxim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100326/7ddfc91f/attachment.html>

From martin.raspaud at smhi.se  Fri Mar 26 09:31:11 2010
From: martin.raspaud at smhi.se (Martin Raspaud)
Date: Fri, 26 Mar 2010 09:31:11 +0100
Subject: [Distutils] Full egg name
Message-ID: <4BAC70CF.4020604@smhi.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I am writing a recipe for buildout, and as such I would like to get the full
name of a develop egg programatically as it would appear if I installed it.
For example if the setup.py defines the name to "myproject", I would like to get
myproject-0.3.0-py2.5-linux-x86_64.egg

How to I get this ?

I look a little bit in the setuptools source code, but it's not easy to find.

Thanks,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLrHDPAAoJEBdvyODiyJI4LhkH/0ep+wfUtAT7IzHdStNUcInT
i9WQx9zyzMmIlWKzgHwSjtN48os3JfKE6iww6QHI6bNH6srDR+dSgeuytfEX8eeh
oMuIYKR5LNgsrol1ZYulQHVz2UGdY308uI4rjxGSFhbwMEs3TGIX4VqrisHK/0uq
RciBMtsa2cmuLrjeTVZVlLHnjGEpili7OUMcjiwcrNch0n24UtuS+hmGDx30E6bl
rGIdr8rWDz7L5KwkbVu/tDAiqy7WRE4uQ8Voc/KDCLks4bXG6CjtcqC264hFqhYS
XmYGqXkk32rJOV6NR2hqAfUapq7EaAVv50DJ2QopvxIiI5lpkxIkgcfbUFvH0aM=
=KIh9
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_raspaud.vcf
Type: text/x-vcard
Size: 259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100326/28db5fe8/attachment.vcf>

From jim at zope.com  Fri Mar 26 11:33:03 2010
From: jim at zope.com (Jim Fulton)
Date: Fri, 26 Mar 2010 06:33:03 -0400
Subject: [Distutils] Buildout documentation
In-Reply-To: <c911c70d1003252330x7f14bfadrfa335194393e5e8b@mail.gmail.com>
References: <c911c70d1003240932t648baad9p4d3b3266bb045154@mail.gmail.com> 
	<c911c70d1003240957w32d1cc95i704833b7c76152f5@mail.gmail.com> 
	<c911c70d1003252330x7f14bfadrfa335194393e5e8b@mail.gmail.com>
Message-ID: <1099b90b1003260333w764d4214n172944a9f46a17b9@mail.gmail.com>

On Fri, Mar 26, 2010 at 2:30 AM, Baiju M <mbaiju at zeomega.com> wrote:
> On Wed, Mar 24, 2010 at 10:27 PM, Baiju M <mbaiju at zeomega.com> wrote:
>> On Wed, Mar 24, 2010 at 10:02 PM, Baiju M <mbaiju at zeomega.com> wrote:
>>> Hi All,
>>> ? ? ? ?I can see many people working with Buildout in this list.
>>> There are nearly 200 packages in PyPI with "Framework :: Buildout"
>>> category: http://pypi.python.org/pypi?:action=browse&c=512
>>> This is really amazing. ?But the documentation for Buildout
>>> is not sufficient. ?I and few others created http://www.buildout.org
>>> during PyCON 2009. ?It would be great, if the users of
>>> Buildout coming forward to maintain that documentation.
>>>
>>> Now Buildout is used by Zope,Plone,Django and many
>>> other projects. ?May be someone can write an entire
>>> book about Buildout :)
>>
>> BTW, if volunteers are coming forward. ?I can coordinate
>> and provide all details required for updating the documentation.
>
> I have created a wiki to document Buildout:
> http://wiki.zope.org/buildout/BuildoutWiki
>
> We will move documentation to official site as it becomes matured.
> Let's see how it works.
>
> The format of wiki is reStructuredText so it would be easy to move
> to Sphinx. To create a wiki link, you can use two square brackets:

Thanks for trying to get this going.

I have a few suggestions:

1. Focus on a few key needs. I think some small efforts could yield
   big pay offs.

2. I think the most important need is for a clear *concise*
   introduction that describes what buildout is for, and it's
   philosophy and one or two simple examples. I think this could be a
   modest effort.

   The essential content for this likely already exists in one of the
   many buildout presentations on buildout.org.

3. For reference, the existing buildout doctests aren't completely
   horrible. :) They could be improved a lot with not too much effort
   by:

    - Converting them to use manuel
    - Commenting test cases that detract from the documentation.

   The idea is not to remove any tests, but to hide tests that detract
   from the documentation and make the remaining ones more readible.

Jim

--
Jim Fulton

From ziade.tarek at gmail.com  Fri Mar 26 11:33:46 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 26 Mar 2010 11:33:46 +0100
Subject: [Distutils] log.py->logging ; trac for distutils2
In-Reply-To: <8e7c74321003260018w1bbe79a7ic0ffdf425b1f8dcb@mail.gmail.com>
References: <8e7c74321003260018w1bbe79a7ic0ffdf425b1f8dcb@mail.gmail.com>
Message-ID: <94bdd2611003260333k1de4752fn20ceeb6ec0bf0099@mail.gmail.com>

On Fri, Mar 26, 2010 at 8:18 AM, Zubin Mithra <zubin.mithra at gmail.com> wrote:
> Hi,
>
> While going through the distutils code base i realized that logging
> was performed with a "log.py" module similar to the logging module in
> stdlib.
>
> Apparently, it documented that the idea was to replace the current
> system using the "logging" module at some point, but it seems that it
> has`nt been done. I`ve made the necessary modifications and will
> upload to bitbucket tomorrow.

that was planned so yes, great that you have done it ! l'll check your work asap

>
> I`ll also do the same for distutils so that maybe, its a backport for distutils?

No, distutils is frozen, so this is not necessary

>
> I had found that this was a pending task by looking through the
> code-base; and the task was quite trivial. I feel that it would be
> great if distutils2 had a "trac" of some sort where we could have
> tickets related to it.
>
> As distutils2 is not part of the python stdlib as of now, it would be
> inappropriate to have those tickets at bugs.python.org , i presume.

distutils2 issues are in bugs.python.org as well (there's a disutils2 component)
since it's going back in the sdtlib eventually,

Regards,
Tarek

>
> Awaiting feedback,
> --
> Zubin Mithra
>
> http://zubin71.wordpress.com
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Fri Mar 26 12:08:50 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 26 Mar 2010 12:08:50 +0100
Subject: [Distutils] Full egg name
In-Reply-To: <4BAC70CF.4020604@smhi.se>
References: <4BAC70CF.4020604@smhi.se>
Message-ID: <94bdd2611003260408s4fc1c4b7u54d691d9527391f2@mail.gmail.com>

On Fri, Mar 26, 2010 at 9:31 AM, Martin Raspaud <martin.raspaud at smhi.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I am writing a recipe for buildout, and as such I would like to get the full
> name of a develop egg programatically as it would appear if I installed it.
> For example if the setup.py defines the name to "myproject", I would like to get
> myproject-0.3.0-py2.5-linux-x86_64.egg
>
> How to I get this ?
>
> I look a little bit in the setuptools source code, but it's not easy to find.

It's provided by the egg_name() function in the Distribution class
(the one in pkg_resources, not the one in setuptools.dist)

>>> from pkg_resources import Distribution, get_build_platform
>>> from distutils.sysconfig import get_python_version
>>> dist = Distribution(None, None, 'myproject', '0.3.0', get_python_version(), get_build_platform())
>>> dist.egg_name() + '.egg'
'myproject-0.3.0-py2.6-macosx-10.3-fat.egg'





>
> Thanks,
> Martin
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJLrHDPAAoJEBdvyODiyJI4LhkH/0ep+wfUtAT7IzHdStNUcInT
> i9WQx9zyzMmIlWKzgHwSjtN48os3JfKE6iww6QHI6bNH6srDR+dSgeuytfEX8eeh
> oMuIYKR5LNgsrol1ZYulQHVz2UGdY308uI4rjxGSFhbwMEs3TGIX4VqrisHK/0uq
> RciBMtsa2cmuLrjeTVZVlLHnjGEpili7OUMcjiwcrNch0n24UtuS+hmGDx30E6bl
> rGIdr8rWDz7L5KwkbVu/tDAiqy7WRE4uQ8Voc/KDCLks4bXG6CjtcqC264hFqhYS
> XmYGqXkk32rJOV6NR2hqAfUapq7EaAVv50DJ2QopvxIiI5lpkxIkgcfbUFvH0aM=
> =KIh9
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>



-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Fri Mar 26 12:19:49 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 26 Mar 2010 12:19:49 +0100
Subject: [Distutils] How to use Nose plugins with buildout
	pbp.recipe.noserunner recipe ?
In-Reply-To: <5bb76e241003260021v18938dcdnf520c75a9f4d5bd8@mail.gmail.com>
References: <5bb76e241003230515u7e7e10efp777be51bf8ba67bf@mail.gmail.com>
	<5bb76e241003260021v18938dcdnf520c75a9f4d5bd8@mail.gmail.com>
Message-ID: <94bdd2611003260419l824dfc2hfed7eefd36889424@mail.gmail.com>

On Fri, Mar 26, 2010 at 8:21 AM, ?????? Lacrima <lacrima.maxim at gmail.com> wrote:
> Hello!
>
> In order if someone is interested how to use Nose plugins with buildout I
> have solved this problem in the following way (without noserunner recipe).
> [enable_plugin]
> recipe = zc.recipe.egg
> eggs = nose
> ?????? nosegae
> ?????? package_under_test
> initialization = from nosegae import NoseGAE
> arguments = addplugins=[NoseGAE()]
> extra-paths = ./parts/google_appengine
> ????????????? ./parts/google_appengine/lib/yaml/lib
>
>
> This works for nosegae plugin, though I don't know if the same approach
> works for other plugins.

Sorry for the late reply.

pbp.recipe.noserunner doesn't have an option to set up plugins, but I
could add a "plugins" option to it if you want,

I am pretty sure there's a simple, generic way to do this since
plugins are "eggs", but I didn't look at it yet

Regards,
Tarek

-- 
Tarek Ziad? | http://ziade.org

From agroszer at gmail.com  Fri Mar 26 13:22:14 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Fri, 26 Mar 2010 13:22:14 +0100
Subject: [Distutils] zc.buildout and "Not upgrading because not running
	a local buildout command"
In-Reply-To: <1011690799.20100324113817@gmail.com>
References: <1011690799.20100324113817@gmail.com>
Message-ID: <713846888.20100326132214@gmail.com>

Hello,

Does anyone know why buildout does NOT want write an upgraded script?
So far I can see it would be easy to write out a "bin/buildout" or a
temporary script.

Wednesday, March 24, 2010, 11:38:17 AM, you wrote:

AG> Hello,

AG> Having problems here with the above.

AG> The thing is that there should be two projects installed on the same
AG> server, but the one is a zope KGS 3.4 the other is a
AG> ztk/bluebream-ish.
AG> The two have different version requirements for setuptools and
AG> zc.buildout.
AG> The buildout.cfg comes from the web like this:
AG> buildout -t 2 -c
AG> http://mypypi.org/++projects++/proj/proj-stage-0.0.4.cfg
AG> (On top of that this is driven by keas.build, but that should not
AG> matter)
AG> Buildout (1.4.1) is installed via easy_install and setuptools (0.6c9).
AG> Therefore the message "Not upgrading because not running a local
AG> buildout command". The message is reasonable, but still makes problems
AG> in the way of making the one of the projects non-installable.

AG> Would not it be easy to create a bin/buildout script and restart with
AG> that?

AG> Or is there any other sane solution for this (that I missed)?



-- 
Best regards,
 Adam GROSZER                            mailto:agroszer at gmail.com
--
Quote of the day:
Angels we have heard on High / Tell us to go out and Buy. -- Tom Lehrer


From jim at zope.com  Fri Mar 26 13:35:15 2010
From: jim at zope.com (Jim Fulton)
Date: Fri, 26 Mar 2010 08:35:15 -0400
Subject: [Distutils] zc.buildout and "Not upgrading because not running
	a local buildout command"
In-Reply-To: <1011690799.20100324113817@gmail.com>
References: <1011690799.20100324113817@gmail.com>
Message-ID: <1099b90b1003260535p43296e81h5a536b8b2bd34196@mail.gmail.com>

On Wed, Mar 24, 2010 at 6:38 AM, Adam GROSZER <agroszer at gmail.com> wrote:
> Hello,
>
> Having problems here with the above.
>
> The thing is that there should be two projects installed on the same
> server, but the one is a zope KGS 3.4 the other is a
> ztk/bluebream-ish.
> The two have different version requirements for setuptools and
> zc.buildout.
> The buildout.cfg comes from the web like this:
> buildout -t 2 -c http://mypypi.org/++projects++/proj/proj-stage-0.0.4.cfg
> (On top of that this is driven by keas.build, but that should not
> matter)
> Buildout (1.4.1) is installed via easy_install and setuptools (0.6c9).
> Therefore the message "Not upgrading because not running a local
> buildout command". The message is reasonable, but still makes problems
> in the way of making the one of the projects non-installable.
>
> Would not it be easy to create a bin/buildout script and restart with
> that?

The auto-upgrade feature of buildout only works if the buildout script
being run is in the buildout's bin directory. This is a safety feature
to avoid unintentional upgrades of other buildouts.

If you installed buildout with easy_install and want to upgrade it, I
suggest upgrading it with easy_install.

Jim

-- 
Jim Fulton

From martin.raspaud at smhi.se  Fri Mar 26 13:35:59 2010
From: martin.raspaud at smhi.se (Martin Raspaud)
Date: Fri, 26 Mar 2010 13:35:59 +0100
Subject: [Distutils] Full egg name
In-Reply-To: <94bdd2611003260408s4fc1c4b7u54d691d9527391f2@mail.gmail.com>
References: <4BAC70CF.4020604@smhi.se>
	<94bdd2611003260408s4fc1c4b7u54d691d9527391f2@mail.gmail.com>
Message-ID: <4BACAA2F.1050908@smhi.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? skrev:
> On Fri, Mar 26, 2010 at 9:31 AM, Martin Raspaud <martin.raspaud at smhi.se> wrote:
> Hi,
> 
> I am writing a recipe for buildout, and as such I would like to get the full
> name of a develop egg programatically as it would appear if I installed it.
> For example if the setup.py defines the name to "myproject", I would like to get
> myproject-0.3.0-py2.5-linux-x86_64.egg
> 
> How to I get this ?
> 
> I look a little bit in the setuptools source code, but it's not easy to find.
> 
>> It's provided by the egg_name() function in the Distribution class
>> (the one in pkg_resources, not the one in setuptools.dist)
> 
>>>>> from pkg_resources import Distribution, get_build_platform
>>>>> from distutils.sysconfig import get_python_version
>>>>> dist = Distribution(None, None, 'myproject', '0.3.0', get_python_version(), get_build_platform())
>>>>> dist.egg_name() + '.egg'
>> 'myproject-0.3.0-py2.6-macosx-10.3-fat.egg'

Nice, thanks !

and how do I get 'myproject' and '0.3.0' from a setup.py file ? (I'm working
with develop eggs)

Regards,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLrKouAAoJEBdvyODiyJI4nfMIAKKuq8AGSJ6j9lzbijD9jOMC
GZXPdtktgNW+/HATQDARZayv8dClu3P33CvOfMrlhW1SpfqvuxMp8G7CWdJhHqG0
purmxH21jldLi2i2EMDN09cC6ehIC71+kaqKUi9wBjjlMIhM0vxsrdcGDNLJpciP
chrVJnyhP42q+KHLffFwmnzdpII4Pkj0vBzOBG2KLaxLHI1ctjLDHcXZkpRyuBkR
+DwtZm3kVaM6IZv9v6d+T4vN3opeg4JbUgwmaQSdlKEhztmlXFH4Qf8TK6YyUdtI
8Y3r1l/IcJwG2az5pFcpvCATEqPsLQQ8Fg4/vfa5EnqMQAaq+xjejOuHIq5LWHE=
=kgUf
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_raspaud.vcf
Type: text/x-vcard
Size: 259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100326/98c5c8a3/attachment.vcf>

From ziade.tarek at gmail.com  Fri Mar 26 13:42:55 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 26 Mar 2010 13:42:55 +0100
Subject: [Distutils] Full egg name
In-Reply-To: <4BACAA2F.1050908@smhi.se>
References: <4BAC70CF.4020604@smhi.se>
	<94bdd2611003260408s4fc1c4b7u54d691d9527391f2@mail.gmail.com>
	<4BACAA2F.1050908@smhi.se>
Message-ID: <94bdd2611003260542g1401f872g9fb6d322c9b54416@mail.gmail.com>

On Fri, Mar 26, 2010 at 1:35 PM, Martin Raspaud <martin.raspaud at smhi.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? skrev:
>> On Fri, Mar 26, 2010 at 9:31 AM, Martin Raspaud <martin.raspaud at smhi.se> wrote:
>> Hi,
>>
>> I am writing a recipe for buildout, and as such I would like to get the full
>> name of a develop egg programatically as it would appear if I installed it.
>> For example if the setup.py defines the name to "myproject", I would like to get
>> myproject-0.3.0-py2.5-linux-x86_64.egg
>>
>> How to I get this ?
>>
>> I look a little bit in the setuptools source code, but it's not easy to find.
>>
>>> It's provided by the egg_name() function in the Distribution class
>>> (the one in pkg_resources, not the one in setuptools.dist)
>>
>>>>>> from pkg_resources import Distribution, get_build_platform
>>>>>> from distutils.sysconfig import get_python_version
>>>>>> dist = Distribution(None, None, 'myproject', '0.3.0', get_python_version(), get_build_platform())
>>>>>> dist.egg_name() + '.egg'
>>> 'myproject-0.3.0-py2.6-macosx-10.3-fat.egg'
>
> Nice, thanks !
>
> and how do I get 'myproject' and '0.3.0' from a setup.py file ? (I'm working
> with develop eggs)

It depends on what your recipe is doing really (and when). If the egg
is already installed in your
environment, by the time your recipe code is run, you can grab these
info using pkg_resources:

>>> pkg_resources.get_distribution('myproject').version, pkg_resources.get_distribution('myproject').project_name

If it's not installed, well, is a bit trickier because you need to run
a command on the project's setup.py.

What are you trying to achieve ?

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From agroszer at gmail.com  Fri Mar 26 14:01:29 2010
From: agroszer at gmail.com (Adam GROSZER)
Date: Fri, 26 Mar 2010 14:01:29 +0100
Subject: [Distutils] zc.buildout and "Not upgrading because not running
	a local buildout command"
In-Reply-To: <1099b90b1003260535p43296e81h5a536b8b2bd34196@mail.gmail.com>
References: <1011690799.20100324113817@gmail.com>
	<1099b90b1003260535p43296e81h5a536b8b2bd34196@mail.gmail.com>
Message-ID: <514738467.20100326140129@gmail.com>

Hello Jim,

What about writing out the upgraded buildout script as a temp script,
like "/tmp/buildout-<random>.py" and restarting with that?

Upgrading with easy_install is a catch 22, one app needs
zc.buildout-1.1.1 the other zc.buildout-1.4.3 nailed via versions.

Friday, March 26, 2010, 1:35:15 PM, you wrote:

JF> On Wed, Mar 24, 2010 at 6:38 AM, Adam GROSZER <agroszer at gmail.com> wrote:
>> Hello,
>>
>> Having problems here with the above.
>>
>> The thing is that there should be two projects installed on the same
>> server, but the one is a zope KGS 3.4 the other is a
>> ztk/bluebream-ish.
>> The two have different version requirements for setuptools and
>> zc.buildout.
>> The buildout.cfg comes from the web like this:
>> buildout -t 2 -c http://mypypi.org/++projects++/proj/proj-stage-0.0.4.cfg
>> (On top of that this is driven by keas.build, but that should not
>> matter)
>> Buildout (1.4.1) is installed via easy_install and setuptools (0.6c9).
>> Therefore the message "Not upgrading because not running a local
>> buildout command". The message is reasonable, but still makes problems
>> in the way of making the one of the projects non-installable.
>>
>> Would not it be easy to create a bin/buildout script and restart with
>> that?

JF> The auto-upgrade feature of buildout only works if the buildout script
JF> being run is in the buildout's bin directory. This is a safety feature
JF> to avoid unintentional upgrades of other buildouts.

JF> If you installed buildout with easy_install and want to upgrade it, I
JF> suggest upgrading it with easy_install.

JF> Jim



-- 
Best regards,
 Adam GROSZER                            mailto:agroszer at gmail.com
--
Quote of the day:
Not only is there no God, but try getting a plumber on the weekend.  -  Woody Allan


From martin.raspaud at smhi.se  Fri Mar 26 15:09:50 2010
From: martin.raspaud at smhi.se (Martin Raspaud)
Date: Fri, 26 Mar 2010 15:09:50 +0100
Subject: [Distutils] Full egg name
In-Reply-To: <94bdd2611003260621m72d34022r5fc2405fad985a0c@mail.gmail.com>
References: <4BAC70CF.4020604@smhi.se>	
	<94bdd2611003260408s4fc1c4b7u54d691d9527391f2@mail.gmail.com>	
	<4BACAA2F.1050908@smhi.se>	
	<94bdd2611003260542g1401f872g9fb6d322c9b54416@mail.gmail.com>	
	<4BACB0E5.7010809@smhi.se>
	<94bdd2611003260621m72d34022r5fc2405fad985a0c@mail.gmail.com>
Message-ID: <4BACC02E.9070709@smhi.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forgot to cc the list...

Tarek Ziad? skrev:
> On Fri, Mar 26, 2010 at 2:04 PM, Martin Raspaud <martin.raspaud at smhi.se> wrote:
> [..]
>> What I want to do is to generate tarballs for our production servers (that have
>> no compiling tools).
>
> I am not sure but, if you are planning to distribute a buildout for
> you production server, what you could do is
> zip a buildout you have built in a similar environment (==a binray
> release of your buildout)
> that contains all the eggs in eggs/  and possibly a download cache
> within the buildout (download/)
>
> Then unzip in on your production server, and with the proper options
> set in you cfg file, you can
> make sure the server will not access pypi or anythong else, and use
> the local cache and eggs,
>
> That's how I do (with some scripts located in collective.releaser),
> and they are alternatives.

Packaging an entire buildout environment is not really an option I think, since
we have several projects using the same eggs, and we think it would be cleaner
to share them (I'm thinking especially of big eggs, like scipy and numpy).

On the other hand, I looked at collective.releaser and it is tempting. I will
talk about this with my boss.

>> The tarball should hold
>> /myproject/myproject-0.3.0-py2.6-macosx-10.3-fat/<all files>
>> in a compiled form (as would be the result of setup.py bdist)
>>
>> The info you gave me is usefull for locally developped packages that I can
>> install as develop eggs.
>> However some of them should be retreived from git, but I thought downloading
>> them first, then put them as develop eggs.
>
> These packages are part of your buildout project or not ?  If they
> are, you can use a project like "mr.developer" to get those locally.

Yes there are. I didn't know about mr.developer, looks nice, thanks !
As for git, I am using zerokspot.recipe.git to retrieve them as develop eggs.

> But again, I am not sure about your release process and how these
> packages are included in your environment so..
>
> If you just want to create standalone binary distributions of single
> python packages, I am not sure how buildout is related, and why you
> are doing a recipe.

Buildout is interesting to me because I can develop, test and use packages in a
clean environment. I don't need to take care of any PYTHONPATH, all dependencies
are installed automatically, and so on. So it is a great tool for development,
and I got this from your book (which is really great by the way).
As such I want to have a recipe for automatically creating packages to deploy on
our servers.
I see that it is indeed not buildout's philosophy build isolated eggs, but it is
not the only thing I use it for :), it is a mere packaging tool for our
production system I am building.

Regards,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLrMAtAAoJEBdvyODiyJI4cjoIAL7o1s7WjR0QSgEgQBSJXaxa
9nlQeFSx0y2ovK4fd3AX/m0FSj4KSf/yiJkG1BDoEPgeaptqUX2lzzp/0XdFbGDn
0t1eSoEL04Py+9eB8FJDzY42vozn54lPo/4cAa9wXW1WQQUJDNkJVh7nm+IYZWei
6PbPT3rY7ETAJAKHcREoAOtJcdrVeU9WhGwEF6nklzmsLNUaEB7kImBisCb/yNKa
soEOXr7j5fc6D8ZCbiOyrtbsnrhcKC1EF+J+0e6bvVTftueCywON1fjULKlelyv1
y7KEPkbMr8o88EAluyW7V21NZ7qZDBkaUoVl8erE6hS8uHBODNzeL2KT0i66j88=
=gjh8
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_raspaud.vcf
Type: text/x-vcard
Size: 259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100326/0c812065/attachment.vcf>

From ziade.tarek at gmail.com  Fri Mar 26 15:19:52 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 26 Mar 2010 15:19:52 +0100
Subject: [Distutils] Full egg name
In-Reply-To: <4BACC02E.9070709@smhi.se>
References: <4BAC70CF.4020604@smhi.se>
	<94bdd2611003260408s4fc1c4b7u54d691d9527391f2@mail.gmail.com>
	<4BACAA2F.1050908@smhi.se>
	<94bdd2611003260542g1401f872g9fb6d322c9b54416@mail.gmail.com>
	<4BACB0E5.7010809@smhi.se>
	<94bdd2611003260621m72d34022r5fc2405fad985a0c@mail.gmail.com>
	<4BACC02E.9070709@smhi.se>
Message-ID: <94bdd2611003260719k6c23860i7c34e3addc61d21b@mail.gmail.com>

On Fri, Mar 26, 2010 at 3:09 PM, Martin Raspaud <martin.raspaud at smhi.se> wrote:
[..]
>
> Packaging an entire buildout environment is not really an option I think, since
> we have several projects using the same eggs, and we think it would be cleaner
> to share them (I'm thinking especially of big eggs, like scipy and numpy).
>

It really depends on your needs and constraints.  I had to ship full
releases to customers.

In your case, you could share the same downloads and eggs folders on
your productions servers maybe,
or run your own PyPI private server to serve the archives to your
buildouts when they claim it.


[..]
>
> Buildout is interesting to me because I can develop, test and use packages in a
> clean environment. I don't need to take care of any PYTHONPATH, all dependencies
> are installed automatically, and so on. So it is a great tool for development,
> and I got this from your book (which is really great by the way).

Great to hear the book helps :)

As a matter of fact, I wrote it right after I had set up a process for
a generic release story with buildouts at a
Plone company, to help developers ship their applications to the customers.


> As such I want to have a recipe for automatically creating packages to deploy on
> our servers.
> I see that it is indeed not buildout's philosophy build isolated eggs, but it is
> not the only thing I use it for :), it is a mere packaging tool for our
> production system I am building.

It makes sense. I use buildout for most web applications production
environments, and I think many people do.
It's just harder to sell if you have a sysadmin in front of you, that
is used to other tools ;)

Tarek

From martin.raspaud at smhi.se  Fri Mar 26 15:40:39 2010
From: martin.raspaud at smhi.se (Martin Raspaud)
Date: Fri, 26 Mar 2010 15:40:39 +0100
Subject: [Distutils] Full egg name
In-Reply-To: <94bdd2611003260719k6c23860i7c34e3addc61d21b@mail.gmail.com>
References: <4BAC70CF.4020604@smhi.se>	
	<94bdd2611003260408s4fc1c4b7u54d691d9527391f2@mail.gmail.com>	
	<4BACAA2F.1050908@smhi.se>	
	<94bdd2611003260542g1401f872g9fb6d322c9b54416@mail.gmail.com>	
	<4BACB0E5.7010809@smhi.se>	
	<94bdd2611003260621m72d34022r5fc2405fad985a0c@mail.gmail.com>	
	<4BACC02E.9070709@smhi.se>
	<94bdd2611003260719k6c23860i7c34e3addc61d21b@mail.gmail.com>
Message-ID: <4BACC767.6000604@smhi.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? skrev:
> On Fri, Mar 26, 2010 at 3:09 PM, Martin Raspaud <martin.raspaud at smhi.se> wrote:
> [..]
>> Packaging an entire buildout environment is not really an option I think, since
>> we have several projects using the same eggs, and we think it would be cleaner
>> to share them (I'm thinking especially of big eggs, like scipy and numpy).
>>
> 
> It really depends on your needs and constraints.  I had to ship full
> releases to customers.
> 
> In your case, you could share the same downloads and eggs folders on
> your productions servers maybe,

Yes, indeed.

> or run your own PyPI private server to serve the archives to your
> buildouts when they claim it.

That looks tempting, but is it possible to have a private pypi server
distributing binary (ready compiled) eggs ?

I explore these options anyway.

>> As such I want to have a recipe for automatically creating packages to deploy on
>> our servers.
>> I see that it is indeed not buildout's philosophy build isolated eggs, but it is
>> not the only thing I use it for :), it is a mere packaging tool for our
>> production system I am building.
> 
> It makes sense. I use buildout for most web applications production
> environments, and I think many people do.
> It's just harder to sell if you have a sysadmin in front of you, that
> is used to other tools ;)

:) exactly...

Regards,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLrMdnAAoJEBdvyODiyJI4hD4IAMrf8QBe1y5WeG0dK3effCPJ
LrtrwsphCNhX7fEbfpmrhXB/b9tYXLBdxU1/GWrrTB/F1OukEoY1S3k76RBIN6YX
beW3tr7+JFg6BvBQaZ1x+/zWCiIxLDcoCq5GYYs/HHmw+jObY7lpy+gGqRPJoUqX
ubsjxXKzLKNkrQLK38KOhLDdeyRBGxfEXP2yE7G5LTO9ldKFqqPRk6L21mXK5n0V
YkVEmyb9ypnlgeLwNUKMYJqH7c1XHOaAHXuddS8xUWkhzewE9eoDZQ1EO5Tto44P
BxY+E8bCvgw1aFWUuj7XrE1PD8pTp+BWbgMEVWBY7FkC8uK8Tiifz4evy/YrZB4=
=xXnI
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_raspaud.vcf
Type: text/x-vcard
Size: 259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100326/eb4d92a1/attachment.vcf>

From ziade.tarek at gmail.com  Fri Mar 26 15:44:29 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 26 Mar 2010 15:44:29 +0100
Subject: [Distutils] How to use Nose plugins with buildout
	pbp.recipe.noserunner recipe ?
In-Reply-To: <5bb76e241003260741v1bdf7e74s4e2050b0eeb2ca50@mail.gmail.com>
References: <5bb76e241003230515u7e7e10efp777be51bf8ba67bf@mail.gmail.com>
	<5bb76e241003260021v18938dcdnf520c75a9f4d5bd8@mail.gmail.com>
	<94bdd2611003260419l824dfc2hfed7eefd36889424@mail.gmail.com>
	<5bb76e241003260741v1bdf7e74s4e2050b0eeb2ca50@mail.gmail.com>
Message-ID: <94bdd2611003260744g6bf2e2cco8d38ab22a1a4d96a@mail.gmail.com>

On Fri, Mar 26, 2010 at 3:41 PM, Maxim Lacrima <lacrima.maxim at gmail.com> wrote:
> Hello!
>
> It would be really nice if there was an option to set up plugins in
> pbp.recipe.noserunner.
> And of course there might be simpler way to enable plugins my solution, but
> I can't figure out how to do this.

I'll have a look sometimes. I think an argument in the command line
(--with-PLUGIN_NAME)
is enough, but I am not familiar with the code

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Fri Mar 26 15:58:16 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 26 Mar 2010 15:58:16 +0100
Subject: [Distutils] Full egg name
In-Reply-To: <4BACC767.6000604@smhi.se>
References: <4BAC70CF.4020604@smhi.se>
	<94bdd2611003260408s4fc1c4b7u54d691d9527391f2@mail.gmail.com>
	<4BACAA2F.1050908@smhi.se>
	<94bdd2611003260542g1401f872g9fb6d322c9b54416@mail.gmail.com>
	<4BACB0E5.7010809@smhi.se>
	<94bdd2611003260621m72d34022r5fc2405fad985a0c@mail.gmail.com>
	<4BACC02E.9070709@smhi.se>
	<94bdd2611003260719k6c23860i7c34e3addc61d21b@mail.gmail.com>
	<4BACC767.6000604@smhi.se>
Message-ID: <94bdd2611003260758q7d5a290eo5ca95eb3b53e7a00@mail.gmail.com>

On Fri, Mar 26, 2010 at 3:40 PM, Martin Raspaud <martin.raspaud at smhi.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? skrev:
>> On Fri, Mar 26, 2010 at 3:09 PM, Martin Raspaud <martin.raspaud at smhi.se> wrote:
>> [..]
>>> Packaging an entire buildout environment is not really an option I think, since
>>> we have several projects using the same eggs, and we think it would be cleaner
>>> to share them (I'm thinking especially of big eggs, like scipy and numpy).
>>>
>>
>> It really depends on your needs and constraints. ?I had to ship full
>> releases to customers.
>>
>> In your case, you could share the same downloads and eggs folders on
>> your productions servers maybe,
>
> Yes, indeed.
>
>> or run your own PyPI private server to serve the archives to your
>> buildouts when they claim it.
>
> That looks tempting, but is it possible to have a private pypi server
> distributing binary (ready compiled) eggs ?
>
> I explore these options anyway.

Yes it is possible, if you upload them to your pypi with:

$ python setup.py bdist_egg register -r YOURPYPI upload -r YOURPYPY

You can use chisop, eggbasket, or PloneSoftwareCenter. (and maybe others)

The last one is great if you want to have a developer's website around
your packages,
will a lot of extra features.

It's overkill if you don't need a website.

That's the one in use at http://plone.org/products

Regards
Tarek

From dsdale24 at gmail.com  Fri Mar 26 18:00:10 2010
From: dsdale24 at gmail.com (Darren Dale)
Date: Fri, 26 Mar 2010 13:00:10 -0400
Subject: [Distutils] question about distribute installation and file
	permissions
Message-ID: <a08e5f81003261000x5f1808c0icba5709535326dfd@mail.gmail.com>

I am looking through my site-packages directories, and it looks like
Distribute installs *.py files with executable permissions. Is this
necessary? Distutils does not do so. Nose, by default, will not run
tests that live in executable modules.

Thanks,
Darren

From pje at telecommunity.com  Fri Mar 26 19:23:34 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 26 Mar 2010 14:23:34 -0400
Subject: [Distutils] log.py->logging ; trac for distutils2
In-Reply-To: <8e7c74321003260018w1bbe79a7ic0ffdf425b1f8dcb@mail.gmail.co
 m>
References: <8e7c74321003260018w1bbe79a7ic0ffdf425b1f8dcb@mail.gmail.com>
Message-ID: <20100326182330.26DE33A4175@sparrow.telecommunity.com>

At 12:48 PM 3/26/2010 +0530, Zubin Mithra wrote:
>I had found that this was a pending task by looking through the
>code-base; and the task was quite trivial.

Did you take into consideration the effect of the -v and -q flags, 
both at the global and specific-command levels?  If not, backporting 
it to the main distutils might be a problem.  (Also, ISTR that the 
logging module by default sends things to stderr that distutils 
currently sends to stdout; that might be a backwards compatibility 
issue as well.)


From ziade.tarek at gmail.com  Fri Mar 26 19:40:03 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 26 Mar 2010 19:40:03 +0100
Subject: [Distutils] log.py->logging ; trac for distutils2
In-Reply-To: <20100326182330.26DE33A4175@sparrow.telecommunity.com>
References: <8e7c74321003260018w1bbe79a7ic0ffdf425b1f8dcb@mail.gmail.com>
	<20100326182330.26DE33A4175@sparrow.telecommunity.com>
Message-ID: <94bdd2611003261140q7fb6e683lca63a15cba2ad53c@mail.gmail.com>

On Fri, Mar 26, 2010 at 7:23 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 12:48 PM 3/26/2010 +0530, Zubin Mithra wrote:
>>
>> I had found that this was a pending task by looking through the
>> code-base; and the task was quite trivial.
>
> Did you take into consideration the effect of the -v and -q flags, both at
> the global and specific-command levels? ?If not, backporting it to the main
> distutils might be a problem. ?(Also, ISTR that the logging module by
> default sends things to stderr that distutils currently sends to stdout;
> that might be a backwards compatibility issue as well.)

FTR, I have done this in the past in a patch and I had
many problems, like the one you mentioned, but also because distutils
is used by Python when the intrepreter starts, and fails because of
the "import logging" chain

Notice that at this point, we won't backport anything but bugfixes in distutils.


>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | http://ziade.org

From jjposner at optimum.net  Fri Mar 26 21:13:12 2010
From: jjposner at optimum.net (John Posner)
Date: Fri, 26 Mar 2010 16:13:12 -0400
Subject: [Distutils] Integrating the packaging guide
In-Reply-To: <4BA640B6.6060407@optimum.net>
References: <4BA3A237.9000701@optimum.net> <4BA3AB3B.6030407@holdenweb.com>
	<4BA3B9B5.8030503@python.org> <4BA3C867.90305@optimum.net>
	<4BA51456.4080302@python.org> <4BA518EE.5090607@optimum.net>
	<94bdd2611003201246v1da3a64dh71b9b4483f2833f9@mail.gmail.com>
	<4BA554E5.4010104@optimum.net>
	<94bdd2611003201613n4de70335g7e966a18b0467200@mail.gmail.com>
	<4BA640B6.6060407@optimum.net>
Message-ID: <4BAD1558.5060700@optimum.net>

On 3/21/2010 11:52 AM, John Posner wrote:
>
>> Thanks for joining and welcome to the team. And Don't Panic ;-)

Not panicking, exactly ...

I've looked over the entire Hitchhiker's Guide. After a very nice Quick 
Start and pretty good initial sections in "Introduction to Packaging", 
things start to get more stream-of-consciousness-y and (to me) 
confusing. This seems to reflect the real world -- the "Current State of 
Packaging" diagram shows that this area of Python functionality is in a 
state of flux.

Here's a bunch of questions -- not necessarily orthogonal to each other 
-- concerning the Guide. I'm posting to the entire SIG, to see if 
there's consensus out there.

1. What is the intended relationship between the Hitchhiker's Guide, a 
short document, and these much lengthier documents:

For *distutils* --

Distributing Python Modules (http://docs.python.org/distutils/index.html)
Installing Python Modules (http://docs.python.org/install/index.html)

For *setuptools* --

Building and Distributing Packages with setuptools 
(http://peak.telecommunity.com/DevCenter/setuptools)

For *distribute* --

Welcome to Distribute?s documentation! 
(http://packages.python.org/distribute/)

2. In the many areas where disutils/setuptools/distribute provide 
overlapping functionality, should the Hitchhiker's Guide promote *the 
one best way* to accomplish a task, or should it compare and contrast 
the various ways?

3. Should the Hitchhiker's Guide be an overview document, with 
cross-refs to large sections of the disutils/setuptools/distribute 
documents? Or should it be a detailed document, with (many more) 
cross-refs to detail sections of the disutils/setuptools/distribute 
documents?

Thanks for helping me get up to speed ...

-John


From pje at telecommunity.com  Fri Mar 26 21:34:10 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 26 Mar 2010 16:34:10 -0400
Subject: [Distutils] Integrating the packaging guide
In-Reply-To: <4BAD1558.5060700@optimum.net>
References: <4BA3A237.9000701@optimum.net> <4BA3AB3B.6030407@holdenweb.com>
	<4BA3B9B5.8030503@python.org> <4BA3C867.90305@optimum.net>
	<4BA51456.4080302@python.org> <4BA518EE.5090607@optimum.net>
	<94bdd2611003201246v1da3a64dh71b9b4483f2833f9@mail.gmail.com>
	<4BA554E5.4010104@optimum.net>
	<94bdd2611003201613n4de70335g7e966a18b0467200@mail.gmail.com>
	<4BA640B6.6060407@optimum.net> <4BAD1558.5060700@optimum.net>
Message-ID: <20100326203406.301673A40AF@sparrow.telecommunity.com>

At 04:13 PM 3/26/2010 -0400, John Posner wrote:
>2. In the many areas where disutils/setuptools/distribute provide 
>overlapping functionality, should the Hitchhiker's Guide promote 
>*the one best way* to accomplish a task, or should it compare and 
>contrast the various ways?

It should provide a recommended One Obvious Way for distutils at 
least - distutils has WAY too many options for how to do things, many 
of them bad or confusing.

For example, package_dir is evil, and I hope it's going away 
altogether in distutils2!

(Actually, in general, whereever distutils2 will be following in 
setuptools' footsteps, that way should probably be the recommended 
way, with the occasional, "here's what you can do in plain disutils 
in the meantime.")


From eire1130 at gmail.com  Sat Mar 27 14:34:28 2010
From: eire1130 at gmail.com (James Reynolds)
Date: Sat, 27 Mar 2010 09:34:28 -0400
Subject: [Distutils] Help with Disutils / MinGW
Message-ID: <98c3f7c51003270634j5b47ad5w19bed728c1a7aa61@mail.gmail.com>

Hello All,

I'm trying to write my first extension module, and I am getting the
following error in my command prompt and I was hoping you all could help me.

I have taken the following steps already:


   1. My path is set for mingw/bin as well as python31.
   2. There is a file in my disutils folder called disutils.cfg that says
   [build] compiler = mingw32
   3. The instructions in the 3.1 documentation state the following: "These
   instructions only apply if you?re using a version of Python prior to 2.4.1
   with a MinGW prior to 3.0.0 (with binutils-2.13.90-20030111-
      1. http://docs.python.org/py3k/install/index.html
      2. I am using Python 3.1 and the latest MinGW.
   4. I tested gcc/mingw by doing C:\python31>gcc -shared pdv.c -o pdv.dll
   and the test was successful (or at least I was not given any errors while
   doing the compile). The pdv is a simple math formula. I am able to use the
   64 bit version of this dll in ctypes, but not the 32 version.
   5. I searched on the internet and the closest thing I can find is the
   following: http://bugs.python.org/issue4709
   6. I suspected I might be having an issue with 64 bit compatibility, but
   I can't get the mingw64 bit compiler to run: "error: don't know how to
   compile C/C++ code on platform 'nt' with 'x86_64-w64-mingw32-gcc' compiler.

I am running Windows 7 64 bit version, I have installed the Python 3.1.2 64
bit interpreter. I have the MinGW32 and the one referenced above as well.

Below you will find the following

One, the error report
two,my setup.py file
three, the file I am trying to turn into a python extension module by
running the following two commands:

python setup.py build
python setup.py install


#1


Microsoft Windows [Version 6.1.7600]

Copyright (c) 2009 Microsoft Corporation.  All rights reserved.


> c:\Python31\Lib\finance>python setup.py build

running build

running build_ext

building 'finance' extension

creating build

creating build\temp.win-amd64-3.1

creating build\temp.win-amd64-3.1\Release

C:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\Python31\include
> -IC:\Pytho

n31\PC -c finance.c -o build\temp.win-amd64-3.1\Release\finance.o

finance.c: In function `PyInit_finance':

finance.c:31: warning: implicit declaration of function `Py_Module_Create'

finance.c:31: warning: return makes pointer from integer without a cast

writing build\temp.win-amd64-3.1\Release\finance.def

creating build\lib.win-amd64-3.1

C:\MinGW\bin\gcc.exe -mno-cygwin -shared -s
> build\temp.win-amd64-3.1\Release\fin

ance.o build\temp.win-amd64-3.1\Release\finance.def -LC:\Python31\libs
> -LC:\Pyth

on31\PCbuild\amd64 -lpython31 -lmsvcr90 -o
> build\lib.win-amd64-3.1\finance.pyd

build\temp.win-amd64-3.1\Release\finance.o:finance.c:(.text+0x2b): undefined
> ref

erence to `_imp__PyArg_ParseTuple'

build\temp.win-amd64-3.1\Release\finance.o:finance.c:(.text+0x5c): undefined
> ref

erence to `_imp__Py_BuildValue'

build\temp.win-amd64-3.1\Release\finance.o:finance.c:(.text+0x74): undefined
> ref

erence to `Py_Module_Create'

collect2: ld returned 1 exit status

error: command 'gcc' failed with exit status 1


> c:\Python31\Lib\finance>



#2


from distutils.core import setup, Extension


> setup(name = "finance",

      version = "1.0",

      ext_modules = [Extension("finance", ["finance.c"])])



#3

#include <Python.h>

#include <math.h>


> static PyObject *

pdv(PyObject *self, PyObject *args)

{

double value, rate, timex, denom, pdvx;

if (!PyArg_ParseTuple(args, "ddd", &value, &rate, &timex))

return NULL;

    denom = (double) pow ((1 + rate), (timex));

    pdvx = value / denom;

return Py_BuildValue("d", pdvx);

}

PyMethodDef pdvMethods[] = {

    {"pdv", pdv, METH_VARARGS, "Returns the Present Discounted Value given
> of a single future value"},

    {NULL, NULL, 0, NULL}

};


> static struct PyModuleDef financemodule = {

   PyModuleDef_HEAD_INIT,

   "finance",   /* name of module */

   NULL, /* module documentation, may be NULL */

   -1,       /* size of per-interpreter state of the module,

                or -1 if the module keeps state in global variables. */

   pdvMethods

};


> PyMODINIT_FUNC

PyInit_finance(void)

{

    return Py_Module_Create(&financemodule);

}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100327/f5fd75c7/attachment.html>

From chris at simplistix.co.uk  Sat Mar 27 19:29:42 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 27 Mar 2010 18:29:42 +0000
Subject: [Distutils] Buildout: Version conflicts with
	system-wide	libraries
In-Reply-To: <1099b90b1003111236o4cdd76f0u5c7db081f96702c@mail.gmail.com>
References: <4B990D1B.5090807@2degreesnetwork.com>	<1099b90b1003110800me2d26ecxbf9e914d5c71a1f@mail.gmail.com>
	<hnb4ts$3s9$1@dough.gmane.org>	<1da06521003110844y30ab997fmc072e78c95fe70cd@mail.gmail.com>
	<1099b90b1003111236o4cdd76f0u5c7db081f96702c@mail.gmail.com>
Message-ID: <4BAE4E96.4070004@simplistix.co.uk>

Jim Fulton wrote:
>> And what does "under review" mean? Is there a development version of
>> bootstrap.py somewhere that we use to can try the new feature?
> 
> It means that there is a branch with the change that I need to review and merge.

Anything we can do to help speed that up?

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From chris at simplistix.co.uk  Sat Mar 27 19:30:56 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 27 Mar 2010 18:30:56 +0000
Subject: [Distutils] Buildout: Version conflicts with
	system-wide	libraries
In-Reply-To: <4B99194E.5010205@2degreesnetwork.com>
References: <4B990D1B.5090807@2degreesnetwork.com>	<1268324465.13354.3.camel@alisah>
	<4B99194E.5010205@2degreesnetwork.com>
Message-ID: <4BAE4EE0.2080506@simplistix.co.uk>

Gustavo Narea wrote:
> On 11/03/10 16:21, Yonsy Solis wrote:
>> use virtualenv with --no-site-packages option, and run your buildout
>> with the python from your virtualenv
>>
>> http://pypi.python.org/pypi/virtualenv
 >
> Thanks, Yonsy. However I already do that :/

Huh? A virtual_env with --no-site-packages should isolate you from 
everything in site-packages.

If it doesn't, please file a bug with the virutal_env guys!

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From jeandaniel.browne at gmail.com  Sat Mar 27 21:15:32 2010
From: jeandaniel.browne at gmail.com (Jean Daniel)
Date: Sat, 27 Mar 2010 21:15:32 +0100
Subject: [Distutils] Buildout: Version conflicts with system-wide
	libraries
In-Reply-To: <4BAE4EE0.2080506@simplistix.co.uk>
References: <4B990D1B.5090807@2degreesnetwork.com>
	<1268324465.13354.3.camel@alisah>
	<4B99194E.5010205@2degreesnetwork.com>
	<4BAE4EE0.2080506@simplistix.co.uk>
Message-ID: <b61c19e71003271315r77764006y4b1f2fc82f338ccb@mail.gmail.com>

It seems to me that once this feature is integrated, there will be
less incentive to use virtualenv.

What cool virtualenv features are left if buildout can do the --no-site-package?





On Sat, Mar 27, 2010 at 7:30 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Gustavo Narea wrote:
>>
>> On 11/03/10 16:21, Yonsy Solis wrote:
>>>
>>> use virtualenv with --no-site-packages option, and run your buildout
>>> with the python from your virtualenv
>>>
>>> http://pypi.python.org/pypi/virtualenv
>
>>
>>
>> Thanks, Yonsy. However I already do that :/
>
> Huh? A virtual_env with --no-site-packages should isolate you from
> everything in site-packages.
>
> If it doesn't, please file a bug with the virutal_env guys!
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
> ? ? ? ? ? - http://www.simplistix.co.uk
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>

From marius at pov.lt  Sat Mar 27 21:47:34 2010
From: marius at pov.lt (Marius Gedminas)
Date: Sat, 27 Mar 2010 22:47:34 +0200
Subject: [Distutils] Buildout: Version conflicts with
	system-wide	libraries
In-Reply-To: <b61c19e71003271315r77764006y4b1f2fc82f338ccb@mail.gmail.com>
References: <4B990D1B.5090807@2degreesnetwork.com>
	<1268324465.13354.3.camel@alisah>
	<4B99194E.5010205@2degreesnetwork.com>
	<4BAE4EE0.2080506@simplistix.co.uk>
	<b61c19e71003271315r77764006y4b1f2fc82f338ccb@mail.gmail.com>
Message-ID: <20100327204734.GA20486@fridge.pov.lt>

On Sat, Mar 27, 2010 at 09:15:32PM +0100, Jean Daniel wrote:
> It seems to me that once this feature is integrated, there will be
> less incentive to use virtualenv.
> 
> What cool virtualenv features are left if buildout can do the
> --no-site-package?

I can easy_install a one-off development tool (RunSnakeRun, restview,
zodbbrowser, zest.releaser, z3c.dependencychecker, a million others)
without having to

  * edit a config file
  * re-run buildout and wait 15 seconds longer than it would take
    otherwise [1]
  * remember to revert my changes lest I commit them and force my tool
    choice on all developers of the project [2]

[1] on my project, a do-nothing-because-nothing-changed
    bin/buildout with newest=false still takes 15 seconds

[2] admittedly, I could create a new empty config file, have it extend
    buildout.cfg, add the extra eggs where necessary, and remember to
    run bin/buildout -c my.cfg.  In practice I always forget the -c and
    only notice when I try to use my extra tools and find them missing,
    which breaks the flow and imposes a 15 second delay.


Don't get the wrong impression; despite occasional frustrations,
buildout is a good tool that does things virtualenv doesn't do, and I
prefer to use buildout for all my Python packages once they stop being
trivially simple.  Buildout's killer feature is the shared egg cache.

Marius Gedminas
-- 
He who sacrifices functionality for ease of use
Loses both and deserves neither
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100327/60502416/attachment.pgp>

From chris at simplistix.co.uk  Sun Mar 28 01:16:41 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Sun, 28 Mar 2010 00:16:41 +0000
Subject: [Distutils] Buildout: Version conflicts
	with	system-wide	libraries
In-Reply-To: <20100327204734.GA20486@fridge.pov.lt>
References: <4B990D1B.5090807@2degreesnetwork.com>	<1268324465.13354.3.camel@alisah>	<4B99194E.5010205@2degreesnetwork.com>	<4BAE4EE0.2080506@simplistix.co.uk>	<b61c19e71003271315r77764006y4b1f2fc82f338ccb@mail.gmail.com>
	<20100327204734.GA20486@fridge.pov.lt>
Message-ID: <4BAE9FE9.1010509@simplistix.co.uk>

Marius Gedminas wrote:
>   * edit a config file

I tend to create new mini-buildouts for this kind of thing...

>   * re-run buildout and wait 15 seconds longer than it would take
>     otherwise [1]

I believe you're looking for either -o, if you have the eggs already, or 
the aforementioned mind buildout.cfg ;-)

> [2] admittedly, I could create a new empty config file, have it extend
>     buildout.cfg,

Why extend? If you're screwing around you only want a small set of eggs...

> Don't get the wrong impression; despite occasional frustrations,
> buildout is a good tool that does things virtualenv doesn't do, and I
> prefer to use buildout for all my Python packages once they stop being
> trivially simple.  Buildout's killer feature is the shared egg cache.

Right, I just wish it didn't have to build the monster sys.path[:]= and 
have its own custom scripts when all you want is an interpreter ;-)

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

From cournape at gmail.com  Sun Mar 28 09:20:02 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sun, 28 Mar 2010 16:20:02 +0900
Subject: [Distutils] Help with Disutils / MinGW
In-Reply-To: <98c3f7c51003270634j5b47ad5w19bed728c1a7aa61@mail.gmail.com>
References: <98c3f7c51003270634j5b47ad5w19bed728c1a7aa61@mail.gmail.com>
Message-ID: <5b8d13221003280020u4ef9045bta6783e0630cb4ee9@mail.gmail.com>

On Sat, Mar 27, 2010 at 10:34 PM, James Reynolds <eire1130 at gmail.com> wrote:
> Hello All,
> I'm trying to write my first extension module, and I am getting the
> following error in my command prompt and I was hoping you all could help me.
> I have taken the following steps already:

Are you trying to build a C extension or something importable by ctypes ?
>
> I am running Windows 7 64 bit version, I have installed the Python 3.1.2 64
> bit interpreter. I have the MinGW32 and the one referenced above as well.

Mingw is useless, since you want to build a 64 bits extension. You
have to use mingw-w64.


>> erence to `_imp__Py_BuildValue'
>>
>> build\temp.win-amd64-3.1\Release\finance.o:finance.c:(.text+0x74):
>> undefined ref
>>
>> erence to `Py_Module_Create'

This is exactly the problem I refered to in the issue 4709 you
mentioned. Since the issue is stalled ATM, you have to define the
necessary macro by yourself in distutils (using define_macros in
setup.py).

Note that mingw-w64 is totally unsupported by python ATM, and you will
have a hard time making it work. By far the easiest solution to build
64 bits extensions on windows is to use MS compilers (which are
available for free).

cheers,

David

From ziade.tarek at gmail.com  Sun Mar 28 17:09:25 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 28 Mar 2010 17:09:25 +0200
Subject: [Distutils] Distutils2@GSOC
Message-ID: <94bdd2611003280809l7968202h169b343e500a777e@mail.gmail.com>

Hello,

I am proposing a Disutils2 topic for GSOC. I have started to list
possible tasks at :

  http://wiki.python.org/moin/SummerOfCode/Distutils2

If you are thinking about some possible tasks, please let me know !

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From techtonik at gmail.com  Mon Mar 29 08:27:27 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 29 Mar 2010 09:27:27 +0300
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <24ea26601003250516i350d625duddc78e72c999a088@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<b654cd2e1003241019r59d788adp749f18a8db0d790c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<4BAA87B5.1050605@dirtcircle.com>
	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
	<24ea26601003250454o73b468d5ha091ef78a8d03dbf@mail.gmail.com>
	<94bdd2611003250509r1ff55a9je9f868e9ba0a054c@mail.gmail.com>
	<24ea26601003250516i350d625duddc78e72c999a088@mail.gmail.com>
Message-ID: <d34314101003282327p1d17d93cub11d92c6bb21accb@mail.gmail.com>

On Thu, Mar 25, 2010 at 2:16 PM, Olemis Lang <olemis at gmail.com> wrote:
> On Thu, Mar 25, 2010 at 8:09 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> On Thu, Mar 25, 2010 at 12:54 PM, Olemis Lang <olemis at gmail.com> wrote:
>>> On Wed, Mar 24, 2010 at 6:19 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>>> On Wed, Mar 24, 2010 at 10:44 PM, Carl Meyer <carl at dirtcircle.com> wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>
>>> [...]
>>>>
>>>>
>>>
>>>
>>
>> I apologize, I know it's hard to follow.
>>
> [...]

It is really hard to follow. You should at least change subjects when
switching topic.

So, what is the verdict? Will there be a package management tool or
bootstrap package for it shipped with Python 2.7 or not?

-- 
anatoly t.

From ziade.tarek at gmail.com  Mon Mar 29 08:37:59 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 08:37:59 +0200
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <d34314101003282327p1d17d93cub11d92c6bb21accb@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<4BAA87B5.1050605@dirtcircle.com>
	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
	<24ea26601003250454o73b468d5ha091ef78a8d03dbf@mail.gmail.com>
	<94bdd2611003250509r1ff55a9je9f868e9ba0a054c@mail.gmail.com>
	<24ea26601003250516i350d625duddc78e72c999a088@mail.gmail.com>
	<d34314101003282327p1d17d93cub11d92c6bb21accb@mail.gmail.com>
Message-ID: <94bdd2611003282337q16474a34i68a155a8f6a42da8@mail.gmail.com>

2010/3/29 anatoly techtonik <techtonik at gmail.com>:
[..]
> It is really hard to follow. You should at least change subjects when
> switching topic.

I was talking about the work going on and the decisions taken lately.

I never change topics of threads mails when there's less than 100 mails,
because I find it way more confusing :)

>
> So, what is the verdict? Will there be a package management tool or
> bootstrap package for it shipped with Python 2.7 or not?

As I said in the mail you've quoted, all improvements are made in
Distutils2. So the answer is no.
Python 2.7b1 is due in less than a week anyways, so any new
development on this topic will happen after.

Basically Python 2.7 == Python 2.6 in term of packaging.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From techtonik at gmail.com  Mon Mar 29 09:30:03 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 29 Mar 2010 10:30:03 +0300
Subject: [Distutils] Bootstrap script for package management tool in Python
	2.7 (Was: Re: [Python-Dev] At least one package management
	tool for 2.7)
Message-ID: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>

So, there won't be any package management tool shipped with Python 2.7
and users will have to download and install `setuptools` manually as
before:

  "search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python
setup.py install"


Therefore I still propose shipping bootstrap package that instruct
user how to download and install an actual package  management tool
when users tries to use it. So far I know only one stable tool -
`easy_install` - a part of `setuptools` package.

The required behavior for very basic user friendliness:
1. user installs Python 2.7
2. user issues `python -m easy_install something`
3. user gets message
'easy_install' tool is not installed on this system. To make it
available, download and install `setuptools` package from
http://pypi.python.org/pypi/setuptools/

4. the screen is paused before exit (for windows systems)

Other design notes:
1. if package tries to import `easy_install` module used for
bootstrap, it gets the same ImportException as if there were no
`easy_install` at all
2. bootstrap module is overwritten by actual package when users installs it


So, do we need a PEP for that? How else can I know if consensus is
reached? Anybody is willing to elaborate on implementation?


P.S. Please be careful to reply to relevant lists
-- 
anatoly t.



On Mon, Mar 29, 2010 at 9:37 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> 2010/3/29 anatoly techtonik <techtonik at gmail.com>:
> [..]
>> It is really hard to follow. You should at least change subjects when
>> switching topic.
>
> I was talking about the work going on and the decisions taken lately.
>
> I never change topics of threads mails when there's less than 100 mails,
> because I find it way more confusing :)
>
>>
>> So, what is the verdict? Will there be a package management tool or
>> bootstrap package for it shipped with Python 2.7 or not?
>
> As I said in the mail you've quoted, all improvements are made in
> Distutils2. So the answer is no.
> Python 2.7b1 is due in less than a week anyways, so any new
> development on this topic will happen after.
>
> Basically Python 2.7 == Python 2.6 in term of packaging.
>
> Regards
> Tarek
>
> --
> Tarek Ziad? | http://ziade.org
>

From ziade.tarek at gmail.com  Mon Mar 29 09:32:54 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 09:32:54 +0200
Subject: [Distutils] PEP 376 Status
In-Reply-To: <887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<4BAB7BCA.2090604@optimum.net>
	<20100325163551.127F43A4080@sparrow.telecommunity.com>
	<94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>
	<887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>
Message-ID: <94bdd2611003290032o49f09147ha16b33d5a3b63d6c@mail.gmail.com>

On Thu, Mar 25, 2010 at 8:56 PM, Sridhar Ratnakumar
<sridharr at activestate.com> wrote:
[..]
>
> +1
> I presume sdist too, if generated with 'python setup.py sdist', will contain
> this .dist-info directory?

I don't think so, because part of the files are generated at installation time.

Do you have something in mind ?

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Mon Mar 29 09:55:08 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 09:55:08 +0200
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
Message-ID: <94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>

On Mon, Mar 29, 2010 at 9:30 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> So, there won't be any package management tool shipped with Python 2.7
> and users will have to download and install `setuptools` manually as
> before:
>
> ?"search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python
> setup.py install"
>
>
> Therefore I still propose shipping bootstrap package that instruct
> user how to download and install an actual package ?management tool
> when users tries to use it. So far I know only one stable tool -
> `easy_install` - a part of `setuptools` package.

There are other tools to install something in a vanilla Python :

- pip  (which also have an uninstall feature)
- distutils
- distribute

>
> The required behavior for very basic user friendliness:
> 1. user installs Python 2.7
> 2. user issues `python -m easy_install something`
> 3. user gets message
> 'easy_install' tool is not installed on this system. To make it
> available, download and install `setuptools` package from
> http://pypi.python.org/pypi/setuptools/

Are you thinking about something generic ?

Like, being able to call :

$ python -m ANYTHING

And get an error message saying that the ANYTHING script is not installed ?
Then have a registry somewhere to get the name of the project that
owns the ANYTHING script ?


[..]
> So, do we need a PEP for that? How else can I know if consensus is
> reached? Anybody is willing to elaborate on implementation?

I see two paths here:
1 - do you want to define a general mechanism for Python to install scripts ?
2 - are you just suggesting to have this mechanism only for Package Managers ?

In case of 2), what you would need to do is propose an extension to
PEP 376, we are currently working
on, then we can add it there once people have discussed it on
distutils-SIG, or maybe create a new PEP if the topic is too big to
fit in 376.

>
>
> P.S. Please be careful to reply to relevant lists

Yes, so if it's 2) let's keep this thread in Distutils-SIG.
Cross-posting like this makes it hard to follow.

Tarek

-- 
Tarek Ziad? | http://ziade.org

From regebro at gmail.com  Mon Mar 29 09:58:59 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 29 Mar 2010 09:58:59 +0200
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
Message-ID: <319e029f1003290058tf8f840bm23e454386570ea9a@mail.gmail.com>

On Mon, Mar 29, 2010 at 09:30, anatoly techtonik <techtonik at gmail.com> wrote:
> Therefore I still propose shipping bootstrap package that instruct
> user how to download and install an actual package ?management tool
> when users tries to use it. So far I know only one stable tool -
> `easy_install` - a part of `setuptools` package.

We can't ship *A* bootstrap script until there is *A* package
management tool in the Python world. Currently there are three. :)

In short: The tools that exist are not ready yet.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Mon Mar 29 10:07:07 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 10:07:07 +0200
Subject: [Distutils] RECORD format in PEP 376
Message-ID: <94bdd2611003290107s779bd82fyc70363578acfe148@mail.gmail.com>

Hello,

I'd like to make the RECORD file dead simple for PEP 376, and remove
all the relocatable work we've started in it, since it'll go in a
second
file. This would be done in a second phase, with the work done at Pycon.

So what I am proposing to keep in the PEP is this:

===========================
The `RECORD` file is a CSV file, composed of records, one line per
installed file. The ``csv`` module is used to read the file, with
these options:

- field delimiter : `,`
- quoting char :  `"`.
- line terminator : ``os.linesep`` (so ``\r\n`` or ``\n``)

Each record is composed of three elements.

- the file's full **path**, as defined by the target system/
- the **MD5** hash of the file, encoded in hex. Notice that `pyc` and
`pyo` generated files don't have any hash because they are
  automatically produced from `py` files. So checking the hash of the
corresponding `py` file is enough to decide if the file and its
  associated `pyc` or `pyo` files have changed.
- the file's size in bytes

The ``csv`` module is used to generate this file, so the field separator is
",". Any "," characters found within a field is escaped automatically
by ``csv``.

When the file is read, the `U` option is used so the universal newline
support (see PEP 278 [#pep278]_) is activated, avoiding any trouble
reading a file produced on a platform that uses a different new line
terminator.
===========================

I think this is getting close to what Pip has today.

Opinions ?

Regards,
Tarek
-- 
Tarek Ziad? | http://ziade.org

From techtonik at gmail.com  Mon Mar 29 11:02:10 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 29 Mar 2010 12:02:10 +0300
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
Message-ID: <d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>

On Mon, Mar 29, 2010 at 10:55 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>
>> Therefore I still propose shipping bootstrap package that instruct
>> user how to download and install an actual package ?management tool
>> when users tries to use it. So far I know only one stable tool -
>> `easy_install` - a part of `setuptools` package.
>
> There are other tools to install something in a vanilla Python :
>
> - pip ?(which also have an uninstall feature)
> - distutils
> - distribute

distutils is not a `package management` tool, because it doesn't know
anything even about installed packages, not saying anything about
dependencies.

`pip` and `distribute` are unknown for a vast majority of Python
users, so if you have a perspective replacement for `easy_install` -
it can be said in bootstrap package message. There is no problem with
packages that require `setuptools` either - they will require
`setuptools` as dependency anyway.

For now there are two questions:
1. Are they stable enough for the replacement of user command line
`easy_install` tool?
2. Which one is the recommended?

P.S. Should there be an accessible FAQ in addition to ML?

>>
>> The required behavior for very basic user friendliness:
>> 1. user installs Python 2.7
>> 2. user issues `python -m easy_install something`
>> 3. user gets message
>> 'easy_install' tool is not installed on this system. To make it
>> available, download and install `setuptools` package from
>> http://pypi.python.org/pypi/setuptools/
>
> Are you thinking about something generic ?
>
> Like, being able to call :
>
> $ python -m ANYTHING
>
> And get an error message saying that the ANYTHING script is not installed ?
> Then have a registry somewhere to get the name of the project that
> owns the ANYTHING script ?
>

No. To get something in 2.7 I would refrain from developing into this
direction for now.

> [..]
>> So, do we need a PEP for that? How else can I know if consensus is
>> reached? Anybody is willing to elaborate on implementation?
>
> I see two paths here:
> 1 - do you want to define a general mechanism for Python to install scripts ?
> 2 - are you just suggesting to have this mechanism only for Package Managers ?

3 - I want current "best practice" for installing Python modules with
dependencies from PyPI to be shipped with Python 2.7 by default

Answering your questions:
1. I want to have some user-friendly way for installing Python
scripts, but I am more concerned that I will miss `easy_install` in
Python 2.7
2. Bootstrap script is aimed at users. Package managers are assumed to
already have their package
at PyPI and provide install instructions that involve `easy_install`,
so nothing is required to be done on their part.

>
> In case of 2), what you would need to do is propose an extension to
> PEP 376, we are currently working
> on, then we can add it there once people have discussed it on
> distutils-SIG, or maybe create a new PEP if the topic is too big to
> fit in 376.

PEP 376 is completely irrelevant to user side boot package proposal.
This proposal is to recommend whatever package managing tool you think
user need and instruct how to get the tool. The boot package doesn't
know anything at all about how packages are managed.


>> P.S. Please be careful to reply to relevant lists
>
> Yes, so if it's 2) let's keep this thread in Distutils-SIG.
> Cross-posting like this makes it hard to follow.

My vision is that decision about having bootstrap package or not in
2.7 should be in python-dev and specific packaging, implementation and
pip/distutils/distribute questions in distutils-sig.

-- 
anatoly t.

From ziade.tarek at gmail.com  Mon Mar 29 11:15:06 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 11:15:06 +0200
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
Message-ID: <94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>

On Mon, Mar 29, 2010 at 11:02 AM, anatoly techtonik <techtonik at gmail.com> wrote:
[..]
> distutils is not a `package management` tool, because it doesn't know
> anything even about installed packages, not saying anything about
> dependencies.

At this point, no one knows anything about installed packages at the
Python level.
Keeping track of installed projects is a feature done within each
package managment system.

And the whole purpose of PEP 376 is to define a database of what's
installed, for the sake of interoperability.

>
> `pip` and `distribute` are unknown for a vast majority of Python
> users, so if you have a perspective replacement for `easy_install` -

Depending on how you call a Python user, I disagree here. Many people
use pip and distribute.

The first one because it has an uninstall feature among other things.
The second one because it fixes some bugs of setuptools and provides
Python 3 support


>
> For now there are two questions:
> 1. Are they stable enough for the replacement of user command line
> `easy_install` tool?
> 2. Which one is the recommended?
>
> P.S. Should there be an accessible FAQ in addition to ML?

This FAQ work has been started in th "HitchHicker's guide to
Packaging" you can find here:

http://guide.python-distribute.org

[..]
> No. To get something in 2.7 I would refrain from developing into this
> direction for now.
>
>> [..]
>>> So, do we need a PEP for that? How else can I know if consensus is
>>> reached? Anybody is willing to elaborate on implementation?
>>
>> I see two paths here:
>> 1 - do you want to define a general mechanism for Python to install scripts ?
>> 2 - are you just suggesting to have this mechanism only for Package Managers ?
>
> 3 - I want current "best practice" for installing Python modules with
> dependencies from PyPI to be shipped with Python 2.7 by default

Again, any new code work will not happen because 2.7 is due in less
than a week. Things are happening in Distutils2.

Now, for the "best practice" documentation, I think the guide is the
best plce to look at.


[..]
> PEP 376 is completely irrelevant to user side boot package proposal.

It is, since it proposes an uninstall script called via -m. So having
a install script called by -m is definitely its business.


> My vision is that decision about having bootstrap package or not in
> 2.7 should be in python-dev and specific packaging, implementation and
> pip/distutils/distribute questions in distutils-sig.

If the mentioned bootstrap script is about a package managment system,
you should keep the discussion in distutils-SIG I think.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Mon Mar 29 11:19:39 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 11:19:39 +0200
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
	<94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
Message-ID: <94bdd2611003290219h11f01c27sf09cd085ea20f7a8@mail.gmail.com>

On Mon, Mar 29, 2010 at 11:15 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
[..]
> Depending on how you call a Python user, I disagree here. Many people
> use pip and distribute.

s/how/who     :)

From techtonik at gmail.com  Mon Mar 29 11:24:56 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 29 Mar 2010 12:24:56 +0300
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <319e029f1003290058tf8f840bm23e454386570ea9a@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<319e029f1003290058tf8f840bm23e454386570ea9a@mail.gmail.com>
Message-ID: <d34314101003290224ne71ebd5q40ba60b1b86a17d2@mail.gmail.com>

2010/3/29 Lennart Regebro <regebro at gmail.com>:
> On Mon, Mar 29, 2010 at 09:30, anatoly techtonik <techtonik at gmail.com> wrote:
>> Therefore I still propose shipping bootstrap package that instruct
>> user how to download and install an actual package ?management tool
>> when users tries to use it. So far I know only one stable tool -
>> `easy_install` - a part of `setuptools` package.
>
> We can't ship *A* bootstrap script until there is *A* package
> management tool in the Python world. Currently there are three. :)
>
> In short: The tools that exist are not ready yet.

Ok. How about shipping bootstrap script only for `easy_install` tool for now?

-- 
anatoly t.

From ziade.tarek at gmail.com  Mon Mar 29 11:38:46 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 11:38:46 +0200
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290224ne71ebd5q40ba60b1b86a17d2@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<319e029f1003290058tf8f840bm23e454386570ea9a@mail.gmail.com>
	<d34314101003290224ne71ebd5q40ba60b1b86a17d2@mail.gmail.com>
Message-ID: <94bdd2611003290238x6455c0d0xefa9afb2d2620064@mail.gmail.com>

2010/3/29 anatoly techtonik <techtonik at gmail.com>:
> 2010/3/29 Lennart Regebro <regebro at gmail.com>:
>> On Mon, Mar 29, 2010 at 09:30, anatoly techtonik <techtonik at gmail.com> wrote:
>>> Therefore I still propose shipping bootstrap package that instruct
>>> user how to download and install an actual package ?management tool
>>> when users tries to use it. So far I know only one stable tool -
>>> `easy_install` - a part of `setuptools` package.
>>
>> We can't ship *A* bootstrap script until there is *A* package
>> management tool in the Python world. Currently there are three. :)
>>
>> In short: The tools that exist are not ready yet.
>
> Ok. How about shipping bootstrap script only for `easy_install` tool for now?

-1

I don't see how this will improve the current state. It will make it
worse since the future of packaging for the stldib is being built in
distutils2, and also in Pip.

People that want to use easy_install can install it. It's very simple
and doesn't require more work than what you have described through a
-m call.

The instructions you want to add in that bootstrap script to inform
people belong to the documentation imho. And that's one of the goal of
the packaging guide we are building.

Another suggestion could be to add in the Python installer a notice
about the guide, saying :

"Hey, we are working on packaging right now. Python currently doesn't
ship with a full-featured package manager, you can have a look in this
guide though, for guidance"

I still think you should remove python-dev from the cc list  ;)

Tarek

-- 
Tarek Ziad? | http://ziade.org

From p.f.moore at gmail.com  Mon Mar 29 12:42:21 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 29 Mar 2010 11:42:21 +0100
Subject: [Distutils] [Python-Dev] Bootstrap script for package
	management tool in Python 2.7 (Was: Re: At least one package
	management tool for 2.7)
In-Reply-To: <94bdd2611003290238x6455c0d0xefa9afb2d2620064@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<319e029f1003290058tf8f840bm23e454386570ea9a@mail.gmail.com>
	<d34314101003290224ne71ebd5q40ba60b1b86a17d2@mail.gmail.com>
	<94bdd2611003290238x6455c0d0xefa9afb2d2620064@mail.gmail.com>
Message-ID: <79990c6b1003290342u5c001f74qff07e418076cb2f4@mail.gmail.com>

On 29 March 2010 10:38, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> I still think you should remove python-dev from the cc list ?;)

I don't know what happened with the change of subject and
crossposting, but I'm now seeing 2 copies of every mail, and both
copies are appearing in both python-dev and distutils-sig (probably,
some of that is gmail's fault, but other crosspostings don't make
things this bad...)

Given that nothing will happen in Python 2.7, I agree that python-dev
should be removed.

Given that easy_install is NOT the "one, true answer" that Anatoly
seems to think it is, I'm dubious that anything can or should be done
until distutils2 is published, so I'd suggest that the whole subject
is dropped until distutils2 is available.

Paul.

From ncoghlan at gmail.com  Mon Mar 29 14:10:52 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 29 Mar 2010 22:10:52 +1000
Subject: [Distutils] [Python-Dev] Bootstrap script for package
 management tool in Python	2.7 (Was: Re: At least one package
 management	tool for 2.7)
In-Reply-To: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
Message-ID: <4BB098CC.1000708@gmail.com>

anatoly techtonik wrote:
> So, there won't be any package management tool shipped with Python 2.7
> and users will have to download and install `setuptools` manually as
> before:

Until the discussed package management tools support a robust inventory
and uninstallation system that plays well with directly installed Python
packages, you won't find widespread support on python-dev for endorsing
any of them.

Yes, the people who use them love them for good and valid reasons, but
those who absolutely detest them also do so for good and valid reasons.
While this is still the case, it would be highly inappropriate for
python-dev to include bootstrap scripts that direct users to these
systems, as they're all flawed in their current incarnations (this isn't
the packaging systems' fault - the flaws are largely due to a lack of
supporting infrastructure in the standard library).

The distutils2 work and the various metadata PEPs that have been
approved recently are all about addressing those limitations in the
infrastructure. With those in place and flowing through the Python
package management ecosystem, bootstrapping interoperable package
management tools is likely to become a reasonable option in the future.
But we aren't there yet, and won't be for 2.7 or 3.2. From an outsider's
perspective, the 3.3 time frame appears to be very possible though.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From olemis at gmail.com  Mon Mar 29 14:27:14 2010
From: olemis at gmail.com (Olemis Lang)
Date: Mon, 29 Mar 2010 08:27:14 -0400
Subject: [Distutils] [Python-Dev] At least one package management tool
	for 2.7
In-Reply-To: <d34314101003282327p1d17d93cub11d92c6bb21accb@mail.gmail.com>
References: <d34314101003240259n70b823b4p5988bad01d062a8c@mail.gmail.com>
	<a08e5f81003241053p340deb66pf748dc2422a6fb35@mail.gmail.com>
	<fa34f1941003241106n6a4dfd2cja881241d247f260c@mail.gmail.com>
	<a08e5f81003241404v2d56e030s60ece3a8b9707db0@mail.gmail.com>
	<4BAA87B5.1050605@dirtcircle.com>
	<94bdd2611003241519o36615b85je335cf7bc3e83e55@mail.gmail.com>
	<24ea26601003250454o73b468d5ha091ef78a8d03dbf@mail.gmail.com>
	<94bdd2611003250509r1ff55a9je9f868e9ba0a054c@mail.gmail.com>
	<24ea26601003250516i350d625duddc78e72c999a088@mail.gmail.com>
	<d34314101003282327p1d17d93cub11d92c6bb21accb@mail.gmail.com>
Message-ID: <24ea26601003290527k25a212cfv40689665d1291c84@mail.gmail.com>

2010/3/29 anatoly techtonik <techtonik at gmail.com>:
> On Thu, Mar 25, 2010 at 2:16 PM, Olemis Lang <olemis at gmail.com> wrote:
>> On Thu, Mar 25, 2010 at 8:09 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>> On Thu, Mar 25, 2010 at 12:54 PM, Olemis Lang <olemis at gmail.com> wrote:
>>>> On Wed, Mar 24, 2010 at 6:19 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>>>> On Wed, Mar 24, 2010 at 10:44 PM, Carl Meyer <carl at dirtcircle.com> wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>
>>>> [...]
>>>
>>> I apologize, I know it's hard to follow.
>>>
>> [...]
>
> It is really hard to follow.
>

Specially for people like me not subscribed to distutils-sig and not
using neither distribute nor distutils2 (dev or whatever)

Anyway I encourage all those trying to improve Py pkg management (...
keep up the good work ...) because I am one of those who dreams of
better integration with pkg systems like `apt` (and would like to wake
up some day ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
On adding Hessian (RPC) support for Trac -
http://feedproxy.google.com/~r/simelo-en/~3/Vit6dRudChU/on-adding-hessian-rpc-support-for-trac.html

From techtonik at gmail.com  Mon Mar 29 15:45:40 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 29 Mar 2010 16:45:40 +0300
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
	<94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
Message-ID: <d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>

On Mon, Mar 29, 2010 at 12:15 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> [..]
>> distutils is not a `package management` tool, because it doesn't know
>> anything even about installed packages, not saying anything about
>> dependencies.
>
> At this point, no one knows anything about installed packages at the
> Python level.

Users do not care about this, and `distutils` doesn't know this even
at package level.

> Keeping track of installed projects is a feature done within each
> package managment system.
>
> And the whole purpose of PEP 376 is to define a database of what's
> installed, for the sake of interoperability.

That's great. When it will be ready everybody would be happy to make
their package management tool compliant.

>>
>> `pip` and `distribute` are unknown for a vast majority of Python
>> users, so if you have a perspective replacement for `easy_install` -
>
> Depending on how you call a Python user, I disagree here. Many people
> use pip and distribute.
>
> The first one because it has an uninstall feature among other things.
> The second one because it fixes some bugs of setuptools and provides
> Python 3 support

I do not mind if we can distribute three stubs, they will also serve
as pointers for a better way of packaging when an ultimate tool is
finally born. Me personally is willing to elaborate for `easy_install`
stub in 2.7.

>>
>> For now there are two questions:
>> 1. Are they stable enough for the replacement of user command line
>> `easy_install` tool?
>> 2. Which one is the recommended?
>>
>> P.S. Should there be an accessible FAQ in addition to ML?
>
> This FAQ work has been started in th "HitchHicker's guide to
> Packaging" you can find here:
>
> http://guide.python-distribute.org

I can see any FAQ. To me the FAQ is something that could be posted to
distutils ML once a month to reflect current state of packaging. It
should also carry version number. So anybody can comment on the FAQ,
ask another question or ask to make a change.

> Again, any new code work will not happen because 2.7 is due in less
> than a week. Things are happening in Distutils2.

That doesn't solve the problem. Bootstrap script can be written in one
day. What we need is a consensus whatever this script is welcomed in
2.7 or not? Who is the person to make the decision?

> Now, for the "best practice" documentation, I think the guide is the
> best plce to look at.

Let's refer to original user story:
"I installed Python and need a quick way to install my packages on top of it."
"I execute `easy_install something` as said in installation manual,
but nothing/error happens."

> [..]
>> PEP 376 is completely irrelevant to user side boot package proposal.
>
> It is, since it proposes an uninstall script called via -m. So having
> a install script called by -m is definitely its business.

The scope of my proposal is a bootstrap script that instructs user how
to install the package management tool of user's choice if this tool
is not yet installed on user system (this is the case with new Python
installation).  If you'll come up with a better way of package
management - you will update this bootstrap script with relevant
information in future Python releases.

Right now it is essential to get this _feature_ in Python 2.7 until
2.7 is frozen for new features. The script that shows message upon
invocation and is overwritten by the version of the package it
proposes to install. Is it hard to do?

>> My vision is that decision about having bootstrap package or not in
>> 2.7 should be in python-dev and specific packaging, implementation and
>> pip/distutils/distribute questions in distutils-sig.
>
> If the mentioned bootstrap script is about a package managment system,
> you should keep the discussion in distutils-SIG I think.

If there will be no bootstrap script in 2.7, I won't have any
motivation to continue discussion until 2.8 deadline is near. Of
course I will be disappointed, because I will have to explain
everything to 2.7 users again and again instead of letting them
execute one command and follow its instructions.
-- 
anatoly t.

From rrr at ronadam.com  Mon Mar 29 15:52:39 2010
From: rrr at ronadam.com (Ron Adam)
Date: Mon, 29 Mar 2010 08:52:39 -0500
Subject: [Distutils] Bootstrap script for package management tool in
 Python 2.7 (Was: Re: [Python-Dev] At least one package management tool for
 2.7)
In-Reply-To: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
Message-ID: <4BB0B0A7.4060405@ronadam.com>



anatoly techtonik wrote:
> So, there won't be any package management tool shipped with Python 2.7
> and users will have to download and install `setuptools` manually as
> before:
> 
>   "search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python
> setup.py install"
> 
> 
> Therefore I still propose shipping bootstrap package that instruct
> user how to download and install an actual package  management tool
> when users tries to use it. So far I know only one stable tool -
> `easy_install` - a part of `setuptools` package.
> 
> The required behavior for very basic user friendliness:
> 1. user installs Python 2.7
> 2. user issues `python -m easy_install something`
> 3. user gets message
> 'easy_install' tool is not installed on this system. To make it
> available, download and install `setuptools` package from
> http://pypi.python.org/pypi/setuptools/
> 
> 4. the screen is paused before exit (for windows systems)
> 
> Other design notes:
> 1. if package tries to import `easy_install` module used for
> bootstrap, it gets the same ImportException as if there were no
> `easy_install` at all
> 2. bootstrap module is overwritten by actual package when users installs it
> 
> 
> So, do we need a PEP for that? How else can I know if consensus is
> reached? Anybody is willing to elaborate on implementation?
> 
> 
> P.S. Please be careful to reply to relevant lists

An even lighter option would be to add an item to pythons 'help' feature.

Currently help("PACKAGES") == help("import")

It may be enough at this time to add a "PACKAGES" help entry that gives an 
overview of packages and hints on installing them.  Then "import" can be a 
related help topic for "PACKAGES".

Ron








From regebro at gmail.com  Mon Mar 29 15:57:04 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 29 Mar 2010 15:57:04 +0200
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com> 
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com> 
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
Message-ID: <319e029f1003290657r2a15dbc7s131b83f51f731218@mail.gmail.com>

On Mon, Mar 29, 2010 at 11:02, anatoly techtonik <techtonik at gmail.com> wrote:
> distutils is not a `package management` tool, because it doesn't know
> anything even about installed packages

With that definition, there are no packaga management tools for
Python. So it's going to be pretty hard to ship one with 2.7.

> `pip` and `distribute` are unknown for a vast majority of Python
> users, so if you have a perspective replacement for `easy_install` -
> it can be said in bootstrap package message. There is no problem with
> packages that require `setuptools` either - they will require
> `setuptools` as dependency anyway.
>
> For now there are two questions:
> 1. Are they stable enough for the replacement of user command line
> `easy_install` tool?

Yes. But that's the wrong question. The correct question is: Are they
stable enough to be included in standard library. And the answer is
"no".

> 2. Which one is the recommended?

Both.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64

From cournape at gmail.com  Mon Mar 29 15:58:32 2010
From: cournape at gmail.com (David Cournapeau)
Date: Mon, 29 Mar 2010 22:58:32 +0900
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
	<94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
	<d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>
Message-ID: <5b8d13221003290658j4734d46atd373b0d389367d4@mail.gmail.com>

On Mon, Mar 29, 2010 at 10:45 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Mon, Mar 29, 2010 at 12:15 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> [..]
>>> distutils is not a `package management` tool, because it doesn't know
>>> anything even about installed packages, not saying anything about
>>> dependencies.
>>
>> At this point, no one knows anything about installed packages at the
>> Python level.
>
> Users do not care about this, and `distutils` doesn't know this even
> at package level.
>
>> Keeping track of installed projects is a feature done within each
>> package managment system.
>>
>> And the whole purpose of PEP 376 is to define a database of what's
>> installed, for the sake of interoperability.
>
> That's great. When it will be ready everybody would be happy to make
> their package management tool compliant.
>
>>>
>>> `pip` and `distribute` are unknown for a vast majority of Python
>>> users, so if you have a perspective replacement for `easy_install` -
>>
>> Depending on how you call a Python user, I disagree here. Many people
>> use pip and distribute.
>>
>> The first one because it has an uninstall feature among other things.
>> The second one because it fixes some bugs of setuptools and provides
>> Python 3 support
>
> I do not mind if we can distribute three stubs, they will also serve
> as pointers for a better way of packaging when an ultimate tool is
> finally born. Me personally is willing to elaborate for `easy_install`
> stub in 2.7.
>
>>>
>>> For now there are two questions:
>>> 1. Are they stable enough for the replacement of user command line
>>> `easy_install` tool?
>>> 2. Which one is the recommended?
>>>
>>> P.S. Should there be an accessible FAQ in addition to ML?
>>
>> This FAQ work has been started in th "HitchHicker's guide to
>> Packaging" you can find here:
>>
>> http://guide.python-distribute.org
>
> I can see any FAQ. To me the FAQ is something that could be posted to
> distutils ML once a month to reflect current state of packaging. It
> should also carry version number. So anybody can comment on the FAQ,
> ask another question or ask to make a change.
>
>> Again, any new code work will not happen because 2.7 is due in less
>> than a week. Things are happening in Distutils2.
>
> That doesn't solve the problem. Bootstrap script can be written in one
> day. What we need is a consensus whatever this script is welcomed in
> 2.7 or not? Who is the person to make the decision?
>
>> Now, for the "best practice" documentation, I think the guide is the
>> best plce to look at.
>
> Let's refer to original user story:
> "I installed Python and need a quick way to install my packages on top of it."

python setup.py install works well, and has for almost a decade.

If you need setuptools, you can include ez_setup.py, which does
exactly what you want, without adding a hugely controversial feature
to python proper. You do something like:

try:
     import setuptools
except ImportError:
     print "Run ez_setup.py first"
     ....

And you're done,

cheers,

David

From regebro at gmail.com  Mon Mar 29 15:59:47 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 29 Mar 2010 15:59:47 +0200
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290224ne71ebd5q40ba60b1b86a17d2@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com> 
	<319e029f1003290058tf8f840bm23e454386570ea9a@mail.gmail.com> 
	<d34314101003290224ne71ebd5q40ba60b1b86a17d2@mail.gmail.com>
Message-ID: <319e029f1003290659j2243ef5dv473805c9df67b250@mail.gmail.com>

2010/3/29 anatoly techtonik <techtonik at gmail.com>:
> Ok. How about shipping bootstrap script only for `easy_install` tool for now?

Since there are many who are of the opinion that easy_install isn't
very good, and pip should be used instead, that would be a bad idea.


Just drop it. 2.7 will not have a package management tool or bootstrap
script to one, because there is currently not one that is good enough
to be the standard. People are working on making the situation good
enough, this debate is wasting their time.

The end.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64

From techtonik at gmail.com  Mon Mar 29 16:00:53 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 29 Mar 2010 17:00:53 +0300
Subject: [Distutils] [Python-Dev] Bootstrap script for package
	management tool in Python 2.7 (Was: Re: At least one package
	management tool for 2.7)
In-Reply-To: <79990c6b1003290342u5c001f74qff07e418076cb2f4@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<319e029f1003290058tf8f840bm23e454386570ea9a@mail.gmail.com>
	<d34314101003290224ne71ebd5q40ba60b1b86a17d2@mail.gmail.com>
	<94bdd2611003290238x6455c0d0xefa9afb2d2620064@mail.gmail.com>
	<79990c6b1003290342u5c001f74qff07e418076cb2f4@mail.gmail.com>
Message-ID: <d34314101003290700n809a0d8td70ba29bef3ffd24@mail.gmail.com>

On Mon, Mar 29, 2010 at 1:42 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>> I still think you should remove python-dev from the cc list ?;)
>
> I don't know what happened with the change of subject and
> crossposting, but I'm now seeing 2 copies of every mail, and both
> copies are appearing in both python-dev and distutils-sig (probably,
> some of that is gmail's fault, but other crosspostings don't make
> things this bad...)

The same here.  This time the thread was hijacked by software. That's
why I prefer reading Google Groups from the web with optional
subscriptions.

> Given that nothing will happen in Python 2.7, I agree that python-dev
> should be removed.
>
> Given that easy_install is NOT the "one, true answer" that Anatoly
> seems to think it is, I'm dubious that anything can or should be done
> until distutils2 is published, so I'd suggest that the whole subject
> is dropped until distutils2 is available.

It is NOT about UPPMS (Universal Python Package Management Solution) -
it is about small bootstrap Script that Guides User how to install the
package management system the user is trying to execute.

-- 
anatoly t.

From rrr at ronadam.com  Mon Mar 29 15:52:39 2010
From: rrr at ronadam.com (Ron Adam)
Date: Mon, 29 Mar 2010 08:52:39 -0500
Subject: [Distutils] Bootstrap script for package management tool in
 Python 2.7 (Was: Re: [Python-Dev] At least one package management tool for
 2.7)
In-Reply-To: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
Message-ID: <4BB0B0A7.4060405@ronadam.com>



anatoly techtonik wrote:
> So, there won't be any package management tool shipped with Python 2.7
> and users will have to download and install `setuptools` manually as
> before:
> 
>   "search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python
> setup.py install"
> 
> 
> Therefore I still propose shipping bootstrap package that instruct
> user how to download and install an actual package  management tool
> when users tries to use it. So far I know only one stable tool -
> `easy_install` - a part of `setuptools` package.
> 
> The required behavior for very basic user friendliness:
> 1. user installs Python 2.7
> 2. user issues `python -m easy_install something`
> 3. user gets message
> 'easy_install' tool is not installed on this system. To make it
> available, download and install `setuptools` package from
> http://pypi.python.org/pypi/setuptools/
> 
> 4. the screen is paused before exit (for windows systems)
> 
> Other design notes:
> 1. if package tries to import `easy_install` module used for
> bootstrap, it gets the same ImportException as if there were no
> `easy_install` at all
> 2. bootstrap module is overwritten by actual package when users installs it
> 
> 
> So, do we need a PEP for that? How else can I know if consensus is
> reached? Anybody is willing to elaborate on implementation?
> 
> 
> P.S. Please be careful to reply to relevant lists

An even lighter option would be to add an item to pythons 'help' feature.

Currently help("PACKAGES") == help("import")

It may be enough at this time to add a "PACKAGES" help entry that gives an 
overview of packages and hints on installing them.  Then "import" can be a 
related help topic for "PACKAGES".

Ron








From ziade.tarek at gmail.com  Mon Mar 29 16:18:03 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 16:18:03 +0200
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
	<94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
	<d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>
Message-ID: <94bdd2611003290718m45d444acs8670404d9a5f3e5f@mail.gmail.com>

On Mon, Mar 29, 2010 at 3:45 PM, anatoly techtonik <techtonik at gmail.com> wrote:
[..]
>> http://guide.python-distribute.org
>
> I can see any FAQ. To me the FAQ is something that could be posted to
> distutils ML once a month to reflect current state of packaging. It
> should also carry version number. So anybody can comment on the FAQ,
> ask another question or ask to make a change.

The guide was built by people in the community, and contains a
"current state of packaging" section.
We are trying to keep it accurate with what we are doing.

You have a mailing list where you can ask question, and you are
welcome to contribute changes.

Adding a "FAQ" containing links to sections in the guide, or a
summarized answered is a good idea though !

>
>> Again, any new code work will not happen because 2.7 is due in less
>> than a week. Things are happening in Distutils2.
>
> That doesn't solve the problem. Bootstrap script can be written in one
> day. What we need is a consensus whatever this script is welcomed in
> 2.7 or not? Who is the person to make the decision?

Guido makes all final decisions.

But before he does, in general, we work all together to find a
consensus, because he can't take part in all
discussions. In this process, I am the guy in charge for packaging
matters in the stdlib, and I am trying to write the PEPs that reflects
those consensus. But anyone is welcome to champion a PEP as long as we
discuss it a bit here, and we agree that a new PEP is required.

Feel free to make more points here in distutils-SIG about your idea,
to explain the advantages of doing it
and gain traction.

But there are no chance at all this will be accepted for 2.7. It's a
long process (not writing a script, but deciding if it's the best way
to go)

>
>> Now, for the "best practice" documentation, I think the guide is the
>> best plce to look at.
>
> Let's refer to original user story:
> "I installed Python and need a quick way to install my packages on top of it."
> "I execute `easy_install something` as said in installation manual,
> but nothing/error happens."

Have you read : http://guide.python-distribute.org/installation.html ?
How could we change it to help this user story ?

>
>> [..]
> The scope of my proposal is a bootstrap script that instructs user how
> to install the package management tool of user's choice if this tool
> is not yet installed on user system (this is the case with new Python
> installation). ?If you'll come up with a better way of package
> management - you will update this bootstrap script with relevant
> information in future Python releases.

Sounds like a simple installation instruction, I can't see the benefit
of adding a script for that.

Plus, we can't make a choice for Python 2.7. Some people use
easy_install, some people use pip,
some use another tool. You use easy_install, fine, install it.

Once PEP 376 is finished and accepted, we might provide a basic script
in the stdlib though.

[..]
> If there will be no bootstrap script in 2.7, I won't have any
> motivation to continue discussion until 2.8 deadline is near. Of
> course I will be disappointed, because I will have to explain
> everything to 2.7 users again and again instead of letting them
> execute one command and follow its instructions.

Frankly, I am not understanding why you are pushing so hard to include
this script one week before 2.7b1 without any previous discussion.  I
am sorry if you feel disappointed about this.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From techtonik at gmail.com  Mon Mar 29 16:21:39 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 29 Mar 2010 17:21:39 +0300
Subject: [Distutils] [Python-Dev] Bootstrap script for package
	management tool in Python 2.7 (Was: Re: At least one package
	management tool for 2.7)
In-Reply-To: <4BB098CC.1000708@gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<4BB098CC.1000708@gmail.com>
Message-ID: <d34314101003290721j4e64b8dbsa9616d196a5c975@mail.gmail.com>

2010/3/29 Nick Coghlan <ncoghlan at gmail.com>:
> anatoly techtonik wrote:
>> So, there won't be any package management tool shipped with Python 2.7
>> and users will have to download and install `setuptools` manually as
>> before:
>
> Until the discussed package management tools support a robust inventory
> and uninstallation system that plays well with directly installed Python
> packages, you won't find widespread support on python-dev for endorsing
> any of them.

This wasn't the question, but the summary. I would greatly appreciate
if you could provide your feedback on the second part of my letter
that started with "Therefore..."


> Yes, the people who use them love them for good and valid reasons, but
> those who absolutely detest them also do so for good and valid reasons.
> While this is still the case, it would be highly inappropriate for
> python-dev to include bootstrap scripts that direct users to these

Scripts do not _direct_ users - they _help_ users, already directed by
some installation instruction or tutorial, to find and install package
management system they are _trying_ to use.

> The distutils2 work and the various metadata PEPs that have been
> approved recently are all about addressing those limitations in the
> infrastructure. With those in place and flowing through the Python
> package management ecosystem, bootstrapping interoperable package
> management tools is likely to become a reasonable option in the future.

Bootstrap tools evolve together with packaging situation. You may
deprecate package management tool in your future bootstrap scripts if
it is "incompatible" with this Python release. It is just user message
that is a flexible as the mind of its author.

> But we aren't there yet, and won't be for 2.7 or 3.2. From an outsider's
> perspective, the 3.3 time frame appears to be very possible though.

Just a thought about user story my customers would likely write if I
shipped Python as a product:
"As a user, I think Python is suxx, because it makes its users suffer
for a long time from packaging disorder".

-- 
anatoly t.

From regebro at gmail.com  Mon Mar 29 16:30:36 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 29 Mar 2010 16:30:36 +0200
Subject: [Distutils] [Python-Dev] Bootstrap script for package
	management tool in Python 2.7 (Was: Re: At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290721j4e64b8dbsa9616d196a5c975@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com> 
	<4BB098CC.1000708@gmail.com>
	<d34314101003290721j4e64b8dbsa9616d196a5c975@mail.gmail.com>
Message-ID: <319e029f1003290730y1a3d3e78s2bf07c284ff2885b@mail.gmail.com>

On Mon, Mar 29, 2010 at 16:21, anatoly techtonik <techtonik at gmail.com> wrote:
> Just a thought about user story my customers would likely write if I
> shipped Python as a product:
> "As a user, I think Python is suxx, because it makes its users suffer
> for a long time from packaging disorder".

So fix it. Python is open source. It's created by it's users. If there
is something you think it lacking, you step up and help make it
better.

But the packaging solution will not be ready for 2.7. It's a really
hard problem. Your help is appreciated. Complaints are not.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64

From techtonik at gmail.com  Mon Mar 29 16:41:38 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 29 Mar 2010 17:41:38 +0300
Subject: [Distutils] FAQ (was: Re: Bootstrap script for package management
	tool in Python 2.7)
Message-ID: <d34314101003290741y203afb7fhae24213a7bdce2ef@mail.gmail.com>

On Mon, Mar 29, 2010 at 5:18 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> [..]
>>> http://guide.python-distribute.org
>>
>> I can see any FAQ. To me the FAQ is something that could be posted to
>> distutils ML once a month to reflect current state of packaging. It
>> should also carry version number. So anybody can comment on the FAQ,
>> ask another question or ask to make a change.
>
> The guide was built by people in the community, and contains a
> "current state of packaging" section.
> We are trying to keep it accurate with what we are doing.
>
> You have a mailing list where you can ask question, and you are
> welcome to contribute changes.
>
> Adding a "FAQ" containing links to sections in the guide, or a
> summarized answered is a good idea though !

If do not post a link to exact chapter in the FAQ as a full response
to user's question at least once a week then it is not a FAQ.

-- 
anatoly t.

From ziade.tarek at gmail.com  Mon Mar 29 16:46:51 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 16:46:51 +0200
Subject: [Distutils] FAQ (was: Re: Bootstrap script for package
	management tool in Python 2.7)
In-Reply-To: <d34314101003290741y203afb7fhae24213a7bdce2ef@mail.gmail.com>
References: <d34314101003290741y203afb7fhae24213a7bdce2ef@mail.gmail.com>
Message-ID: <94bdd2611003290746v9004f9o457051abab0464b7@mail.gmail.com>

On Mon, Mar 29, 2010 at 4:41 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Mon, Mar 29, 2010 at 5:18 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> [..]
>>>> http://guide.python-distribute.org
>>>
>>> I can see any FAQ. To me the FAQ is something that could be posted to
>>> distutils ML once a month to reflect current state of packaging. It
>>> should also carry version number. So anybody can comment on the FAQ,
>>> ask another question or ask to make a change.
>>
>> The guide was built by people in the community, and contains a
>> "current state of packaging" section.
>> We are trying to keep it accurate with what we are doing.
>>
>> You have a mailing list where you can ask question, and you are
>> welcome to contribute changes.
>>
>> Adding a "FAQ" containing links to sections in the guide, or a
>> summarized answered is a good idea though !
>
> If do not post a link to exact chapter in the FAQ as a full response
> to user's question at least once a week then it is not a FAQ.

I don't understand what's "once a week" means.

For me a FAQ is a list of questions. We add a new question everytime someone
ask it and it doesn't exists. We correct the answers when they evolve.
No matter when these events occur.

>
> --
> anatoly t.
>



-- 
Tarek Ziad? | http://ziade.org

From techtonik at gmail.com  Mon Mar 29 17:32:44 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 29 Mar 2010 18:32:44 +0300
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <94bdd2611003290718m45d444acs8670404d9a5f3e5f@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
	<94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
	<d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>
	<94bdd2611003290718m45d444acs8670404d9a5f3e5f@mail.gmail.com>
Message-ID: <d34314101003290832k52de07a4l2f0405b792ffdabe@mail.gmail.com>

On Mon, Mar 29, 2010 at 5:18 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>
>>> Again, any new code work will not happen because 2.7 is due in less
>>> than a week. Things are happening in Distutils2.
>>
>> That doesn't solve the problem. Bootstrap script can be written in one
>> day. What we need is a consensus whatever this script is welcomed in
>> 2.7 or not? Who is the person to make the decision?
>
> Guido makes all final decisions.
>
> But before he does, in general, we work all together to find a
> consensus, because he can't take part in all
> discussions. In this process, I am the guy in charge for packaging
> matters in the stdlib, and I am trying to write the PEPs that reflects
> those consensus. But anyone is welcome to champion a PEP as long as we
> discuss it a bit here, and we agree that a new PEP is required.
>
> Feel free to make more points here in distutils-SIG about your idea,
> to explain the advantages of doing it
> and gain traction.

So far I haven't seen any counter arguments against _bootstrap script_
itself. I see that the difference between "package management tool"
and "bootstrap script" should be defined more clearly. But I do not
know how.

> But there are no chance at all this will be accepted for 2.7. It's a
> long process (not writing a script, but deciding if it's the best way
> to go)

Ok. It seemed so simple, so that I do not even know if I able to
propose anything at all. It takes an enormous amount of time and
effort to keep discussion focused.

>>> Now, for the "best practice" documentation, I think the guide is the
>>> best plce to look at.
>>
>> Let's refer to original user story:
>> "I installed Python and need a quick way to install my packages on top of it."
>> "I execute `easy_install something` as said in installation manual,
>> but nothing/error happens."
>
> Have you read : http://guide.python-distribute.org/installation.html ?
> How could we change it to help this user story ?

1. Provide a less "boring" version for users who are not interested in
details of package management history
2. It doesn't describe what command on windows should I use (and I am
on windows) to "wget" distribute_setup.py
3. Too complicated for a user

To completely get the picture - imagine a typical student who learns
English as a second language. If the person has weak language skill -
he will skip directly to examples, believe me. Even I do this. And
your examples are not crossplatform, and this complicates things even
more.

"packaging ecosystem manipulation", "combination of tool used for
ecosystem isolation and two other tools", argumentation that
"Distribute was created because the Setuptools package is no longer
maintained". It is all aimed at Python developers, probably with
bachelor's degree. I speak on behalf of user that doesn't know
anything about Python besides that it should be installed along with
some API package to turn on support for youtube video sharing.

>> The scope of my proposal is a bootstrap script that instructs user how
>> to install the package management tool of user's choice if this tool
>> is not yet installed on user system (this is the case with new Python
>> installation). ?If you'll come up with a better way of package
>> management - you will update this bootstrap script with relevant
>> information in future Python releases.
>
> Sounds like a simple installation instruction, I can't see the benefit
> of adding a script for that.

Of course! Because you are a developer. You need to be a user or at
least QA engineer to see it. =)

For now in its simplest minimal form that is possible to create in a
day for 2.7 it is an simple text instruction. This will surely can be
ready for 2.7. But in future distributions, i.e. in Python 2.7
non-beta, it may be able to download required package management tool
automatically if user agrees, unpack it to %TEMP% and execute
"setup.py install".

> Plus, we can't make a choice for Python 2.7. Some people use
> easy_install, some people use pip,
> some use another tool. You use easy_install, fine, install it.

Some people just blindly follow the instructions and they are disappointed if:
1. it doesn't work
2. if the thing need to be done quickly and instruction is too long
3. if instruction is too long and it still doesn't work

> Once PEP 376 is finished and accepted, we might provide a basic script
> in the stdlib though.

I can see immediate benefit in this script now, but I can not predict
if it will be actual 5 years later. =)

> [..]
>> If there will be no bootstrap script in 2.7, I won't have any
>> motivation to continue discussion until 2.8 deadline is near. Of
>> course I will be disappointed, because I will have to explain
>> everything to 2.7 users again and again instead of letting them
>> execute one command and follow its instructions.
>
> Frankly, I am not understanding why you are pushing so hard to include
> this script one week before 2.7b1 without any previous discussion. ?I
> am sorry if you feel disappointed about this.

I can't comment anything about it. It is too subjective, like no time,
no Python 2.7 installation until alpha 4 (because I want to see yet
another trivial patch with hijacked discussion included there), not
being able to get back to problem, because installing `setuptools` for
me as a developer is faster than describing user problems. I could
also add that mailing lists are archaic to my taste, Python lists are
too flooded, it is hard to follow up on threads, that there are always
much more ideas that I able to type at any given moment.
-- 
anatoly t.

From regebro at gmail.com  Mon Mar 29 17:35:23 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 29 Mar 2010 17:35:23 +0200
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290832k52de07a4l2f0405b792ffdabe@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com> 
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com> 
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com> 
	<94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com> 
	<d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com> 
	<94bdd2611003290718m45d444acs8670404d9a5f3e5f@mail.gmail.com> 
	<d34314101003290832k52de07a4l2f0405b792ffdabe@mail.gmail.com>
Message-ID: <319e029f1003290835k1c515785raad51c2f3a23165e@mail.gmail.com>

On Mon, Mar 29, 2010 at 17:32, anatoly techtonik <techtonik at gmail.com> wrote:
> So far I haven't seen any counter arguments against _bootstrap script_
> itself. I see that the difference between "package management tool"
> and "bootstrap script" should be defined more clearly. But I do not
> know how.

What difference? The bootstrap script would bootstrap a package
management tool. But non exists that is good enough for everyone to
agree on at the moment. So there is nothing to bootstrap.

You are asking for inclusion of something that does not yet exist.
It's self-evident that this is impossible.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64

From cournape at gmail.com  Mon Mar 29 17:37:39 2010
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 30 Mar 2010 00:37:39 +0900
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290832k52de07a4l2f0405b792ffdabe@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
	<94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
	<d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>
	<94bdd2611003290718m45d444acs8670404d9a5f3e5f@mail.gmail.com>
	<d34314101003290832k52de07a4l2f0405b792ffdabe@mail.gmail.com>
Message-ID: <5b8d13221003290837v4099bdb2g40fedf0ddc214e9d@mail.gmail.com>

On Tue, Mar 30, 2010 at 12:32 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Mon, Mar 29, 2010 at 5:18 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>>
>>>> Again, any new code work will not happen because 2.7 is due in less
>>>> than a week. Things are happening in Distutils2.
>>>
>>> That doesn't solve the problem. Bootstrap script can be written in one
>>> day. What we need is a consensus whatever this script is welcomed in
>>> 2.7 or not? Who is the person to make the decision?
>>
>> Guido makes all final decisions.
>>
>> But before he does, in general, we work all together to find a
>> consensus, because he can't take part in all
>> discussions. In this process, I am the guy in charge for packaging
>> matters in the stdlib, and I am trying to write the PEPs that reflects
>> those consensus. But anyone is welcome to champion a PEP as long as we
>> discuss it a bit here, and we agree that a new PEP is required.
>>
>> Feel free to make more points here in distutils-SIG about your idea,
>> to explain the advantages of doing it
>> and gain traction.
>
> So far I haven't seen any counter arguments against _bootstrap script_
> itself.

You certainly have not provided any argument *for* one. Again, what's
the point compared to adding the bootstrap script ez_setup.py in your
package.

I also find the easiness argument rather dubious: especially on
windows, the thing to give a user is an installer (.exe/.msi), not
sources. That will solve more problems than any buggy bootstrap script
requiring a working internet connection will ever do,

cheers,

David

From regebro at gmail.com  Mon Mar 29 17:38:02 2010
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 29 Mar 2010 17:38:02 +0200
Subject: [Distutils] FAQ (was: Re: Bootstrap script for package
	management tool in Python 2.7)
In-Reply-To: <94bdd2611003290746v9004f9o457051abab0464b7@mail.gmail.com>
References: <d34314101003290741y203afb7fhae24213a7bdce2ef@mail.gmail.com> 
	<94bdd2611003290746v9004f9o457051abab0464b7@mail.gmail.com>
Message-ID: <319e029f1003290838l754e8f74j6ff0e5119ca2354b@mail.gmail.com>

On Mon, Mar 29, 2010 at 16:46, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> For me a FAQ is a list of questions. We add a new question everytime someone
> ask it and it doesn't exists. We correct the answers when they evolve.
> No matter when these events occur.

I have a suggestion for a good "FAQ". Changing the footer of
distutils-sig to "Stop complaining, start coding!"

:)

From ziade.tarek at gmail.com  Mon Mar 29 17:52:30 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 17:52:30 +0200
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290832k52de07a4l2f0405b792ffdabe@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
	<94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
	<d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>
	<94bdd2611003290718m45d444acs8670404d9a5f3e5f@mail.gmail.com>
	<d34314101003290832k52de07a4l2f0405b792ffdabe@mail.gmail.com>
Message-ID: <94bdd2611003290852q45927cf0v33b0b437c9eaa76f@mail.gmail.com>

On Mon, Mar 29, 2010 at 5:32 PM, anatoly techtonik <techtonik at gmail.com> wrote:
[..]
>>
>> Sounds like a simple installation instruction, I can't see the benefit
>> of adding a script for that.
>
> Of course! Because you are a developer. You need to be a user or at
> least QA engineer to see it. =)
>
> For now in its simplest minimal form that is possible to create in a
> day for 2.7 it is an simple text instruction. This will surely can be
> ready for 2.7. But in future distributions, i.e. in Python 2.7
> non-beta, it may be able to download required package management tool
> automatically if user agrees, unpack it to %TEMP% and execute
> "setup.py install".

You are completely right about the fact that our tools and guide are
aiming to developers.

The CPython distribution comes with the stdlib, no more no less. So
there's no point to launch the installation of a third party project
when you install CPython. And until the stdlib contains what it takes
to have a full-feature package manager, you will need to do an extra
manual installation to get one, or use another Python distribution
that contains one already.

Maybe you should use Python distributions like Enthought's or
ActiveState's ones, that are both including a package manager when you
install them.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From sridharr at activestate.com  Mon Mar 29 18:20:46 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 29 Mar 2010 09:20:46 -0700
Subject: [Distutils] PEP 376 Status
In-Reply-To: <94bdd2611003290032o49f09147ha16b33d5a3b63d6c@mail.gmail.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<4BAB7BCA.2090604@optimum.net>
	<20100325163551.127F43A4080@sparrow.telecommunity.com>
	<94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>
	<887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>
	<94bdd2611003290032o49f09147ha16b33d5a3b63d6c@mail.gmail.com>
Message-ID: <1ABEF90B-4233-4935-9D26-88913A521401@activestate.com>


On 2010-03-29, at 12:32 AM, Tarek Ziad? wrote:

> On Thu, Mar 25, 2010 at 8:56 PM, Sridhar Ratnakumar
> <sridharr at activestate.com> wrote:
> [..]
>> 
>> +1
>> I presume sdist too, if generated with 'python setup.py sdist', will contain
>> this .dist-info directory?
> 
> I don't think so, because part of the files are generated at installation time.
> 
> Do you have something in mind ?


Yes, I read metadata of source distributions by trying to find the PKG-INFO files and extracting at least Name and Version from it (using filenames is unreliable -- eg: "latest.zip"). I thought that due to environment markers and such changes hinting static metadata, the source distribution will at least have METADATA (formerly PKG-INFO) in it. Will that be the case with distutuils2? I know that distutils/setuptools includes PKG-INFO.

-srid




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100329/cfdbe2ed/attachment.html>

From techtonik at gmail.com  Mon Mar 29 18:29:48 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 29 Mar 2010 19:29:48 +0300
Subject: [Distutils] FAQ (was: Re: Bootstrap script for package
	management tool in Python 2.7)
In-Reply-To: <94bdd2611003290746v9004f9o457051abab0464b7@mail.gmail.com>
References: <d34314101003290741y203afb7fhae24213a7bdce2ef@mail.gmail.com>
	<94bdd2611003290746v9004f9o457051abab0464b7@mail.gmail.com>
Message-ID: <d34314101003290929s5d376999pbbc10af3ae749333@mail.gmail.com>

On Mon, Mar 29, 2010 at 5:46 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Mon, Mar 29, 2010 at 4:41 PM, anatoly techtonik <techtonik at gmail.com> wrote:
>> On Mon, Mar 29, 2010 at 5:18 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>> [..]
>>>>> http://guide.python-distribute.org
>>>>
>>>> I can see any FAQ. To me the FAQ is something that could be posted to
>>>> distutils ML once a month to reflect current state of packaging. It
>>>> should also carry version number. So anybody can comment on the FAQ,
>>>> ask another question or ask to make a change.
>>>
>>> The guide was built by people in the community, and contains a
>>> "current state of packaging" section.
>>> We are trying to keep it accurate with what we are doing.
>>>
>>> You have a mailing list where you can ask question, and you are
>>> welcome to contribute changes.
>>>
>>> Adding a "FAQ" containing links to sections in the guide, or a
>>> summarized answered is a good idea though !
>>
>> If do not post a link to exact chapter in the FAQ as a full response
>> to user's question at least once a week then it is not a FAQ.
>
> I don't understand what's "once a week" means.
>
> For me a FAQ is a list of questions. We add a new question everytime someone
> ask it and it doesn't exists. We correct the answers when they evolve.
> No matter when these events occur.

For example, http://www.faqs.org/faqs/happyman-faq/
Note that this is an email and it has version.

If FAQ is posted monthly or weekly - you may refer people to the
relevant mail in archive. Everybody can just reply to a FAQ email to
ask a new question or correct an omission.
-- 
anatoly t.

From techtonik at gmail.com  Mon Mar 29 18:30:57 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 29 Mar 2010 19:30:57 +0300
Subject: [Distutils] FAQ (was: Re: Bootstrap script for package
	management tool in Python 2.7)
In-Reply-To: <319e029f1003290838l754e8f74j6ff0e5119ca2354b@mail.gmail.com>
References: <d34314101003290741y203afb7fhae24213a7bdce2ef@mail.gmail.com>
	<94bdd2611003290746v9004f9o457051abab0464b7@mail.gmail.com>
	<319e029f1003290838l754e8f74j6ff0e5119ca2354b@mail.gmail.com>
Message-ID: <d34314101003290930u51402a49gf8df1f9329d78363@mail.gmail.com>

On Mon, Mar 29, 2010 at 6:38 PM, Lennart Regebro <regebro at gmail.com> wrote:
> On Mon, Mar 29, 2010 at 16:46, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> For me a FAQ is a list of questions. We add a new question everytime someone
>> ask it and it doesn't exists. We correct the answers when they evolve.
>> No matter when these events occur.
>
> I have a suggestion for a good "FAQ". Changing the footer of
> distutils-sig to "Stop complaining, start coding!"
>
> :)
>

So, the first question then.. =)
1. Where should I start?

-- 
anatoly t.

From robert.kern at gmail.com  Mon Mar 29 18:38:05 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 29 Mar 2010 11:38:05 -0500
Subject: [Distutils] FAQ (was: Re: Bootstrap script for package
 management tool in Python 2.7)
In-Reply-To: <d34314101003290929s5d376999pbbc10af3ae749333@mail.gmail.com>
References: <d34314101003290741y203afb7fhae24213a7bdce2ef@mail.gmail.com>	<94bdd2611003290746v9004f9o457051abab0464b7@mail.gmail.com>
	<d34314101003290929s5d376999pbbc10af3ae749333@mail.gmail.com>
Message-ID: <hoql1d$14c$1@dough.gmane.org>

On 2010-03-29 11:29 AM, anatoly techtonik wrote:
> On Mon, Mar 29, 2010 at 5:46 PM, Tarek Ziad?<ziade.tarek at gmail.com>  wrote:
>> On Mon, Mar 29, 2010 at 4:41 PM, anatoly techtonik<techtonik at gmail.com>  wrote:
>>> On Mon, Mar 29, 2010 at 5:18 PM, Tarek Ziad?<ziade.tarek at gmail.com>  wrote:
>>>> [..]
>>>>>> http://guide.python-distribute.org
>>>>>
>>>>> I can see any FAQ. To me the FAQ is something that could be posted to
>>>>> distutils ML once a month to reflect current state of packaging. It
>>>>> should also carry version number. So anybody can comment on the FAQ,
>>>>> ask another question or ask to make a change.
>>>>
>>>> The guide was built by people in the community, and contains a
>>>> "current state of packaging" section.
>>>> We are trying to keep it accurate with what we are doing.
>>>>
>>>> You have a mailing list where you can ask question, and you are
>>>> welcome to contribute changes.
>>>>
>>>> Adding a "FAQ" containing links to sections in the guide, or a
>>>> summarized answered is a good idea though !
>>>
>>> If do not post a link to exact chapter in the FAQ as a full response
>>> to user's question at least once a week then it is not a FAQ.
>>
>> I don't understand what's "once a week" means.
>>
>> For me a FAQ is a list of questions. We add a new question everytime someone
>> ask it and it doesn't exists. We correct the answers when they evolve.
>> No matter when these events occur.
>
> For example, http://www.faqs.org/faqs/happyman-faq/
> Note that this is an email and it has version.
>
> If FAQ is posted monthly or weekly - you may refer people to the
> relevant mail in archive. Everybody can just reply to a FAQ email to
> ask a new question or correct an omission.

This style of maintaining a FAQ has long since fallen out of fashion. No one 
seems to want to volunteer to maintain a FAQ this way, so I suggest dropping the 
issue.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From p.f.moore at gmail.com  Mon Mar 29 21:08:57 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 29 Mar 2010 20:08:57 +0100
Subject: [Distutils] Bootstrap script for package management tool in
	Python 2.7 (Was: Re: [Python-Dev] At least one package
	management tool for 2.7)
In-Reply-To: <d34314101003290832k52de07a4l2f0405b792ffdabe@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
	<94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
	<d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>
	<94bdd2611003290718m45d444acs8670404d9a5f3e5f@mail.gmail.com>
	<d34314101003290832k52de07a4l2f0405b792ffdabe@mail.gmail.com>
Message-ID: <79990c6b1003291208m1c2ecd5cj20649fd25d25fa@mail.gmail.com>

On 29 March 2010 16:32, anatoly techtonik <techtonik at gmail.com> wrote:
> So far I haven't seen any counter arguments against _bootstrap script_
> itself. I see that the difference between "package management tool"
> and "bootstrap script" should be defined more clearly. But I do not
> know how.

You haven't been reading closely, I guess:

1. The script doesn't exist and no-one has stepped up to write it.
2. Three scripts would be required not one (pip, distribute,
setuptools were I think the 3 options mentioned) - and that goes
against the Zen "There should be one obvious way".
3. You have no consensus that this is a good idea.
4. There is no clear target version - you're insisting that this go in
2.7, even though it has been repeatedly and clearly stated that this
is impossible (3.3 is the earliest possible target for something like
this).

And one which hasn't been mentioned yet (that I've noticed), but I'll
add for good measure:

5. You haven't explained what will happen if the target of the
bootstrap (easy_install, or whatever) is removed or otherwise becomes
unavailable, or isn't supported under whatever version of Python is
running (remember, your bootstrap script will need to still be
available at least until Python 3.6, for backward compatibility
reasons if nothing else).

I could come up with more, but these should do.

If you want this to go further, I suggest that you do the following
(all of these, don't expect anyone else to do any of them for you):

1. Write a PEP, proposing the feature, summarising the arguments for
and against as expressed in this thread, addressing all of the
objections (start with the 5 above) and suggesting a target version
for inclusion. That must be 3.3 or later.
2. Write a patch which implements the feature, including tests and
documentation. This can be against trunk. Be prepared to maintain it
over an extended period (i.e. updating it to apply cleanly as needed).
3. Persuade python-dev that the idea has merit - get consensus that
the feature should go in, and get the PEP accepted (I'd be surprised
if you can get this without Tarek's support, which you don't have yet,
so there's your starting point once 1 and 2 are done).

It might be better spending your time on these activities rather than
fanning the flames on distutils-sig in the short term...

Paul.

From p.f.moore at gmail.com  Mon Mar 29 21:10:18 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 29 Mar 2010 20:10:18 +0100
Subject: [Distutils] FAQ (was: Re: Bootstrap script for package
	management tool in Python 2.7)
In-Reply-To: <d34314101003290930u51402a49gf8df1f9329d78363@mail.gmail.com>
References: <d34314101003290741y203afb7fhae24213a7bdce2ef@mail.gmail.com>
	<94bdd2611003290746v9004f9o457051abab0464b7@mail.gmail.com>
	<319e029f1003290838l754e8f74j6ff0e5119ca2354b@mail.gmail.com>
	<d34314101003290930u51402a49gf8df1f9329d78363@mail.gmail.com>
Message-ID: <79990c6b1003291210x2586b970vc66ef1a73946dd14@mail.gmail.com>

On 29 March 2010 17:30, anatoly techtonik <techtonik at gmail.com> wrote:
> So, the first question then.. =)
> 1. Where should I start?

See my previous post. Write a patch, and write a PEP.
Paul.

From martin at v.loewis.de  Mon Mar 29 22:06:20 2010
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 29 Mar 2010 22:06:20 +0200
Subject: [Distutils] Bootstrap script for package management tool in
 Python 2.7 (Was: Re: [Python-Dev] At least one package management	tool for
 2.7)
In-Reply-To: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
Message-ID: <4BB1083C.30509@v.loewis.de>

anatoly techtonik wrote:
> So, there won't be any package management tool shipped with Python 2.7
> and users will have to download and install `setuptools` manually as
> before:
[...]
> So, do we need a PEP for that? How else can I know if consensus is
> reached? Anybody is willing to elaborate on implementation?

Notice that the first beta release of Python 2.7 will be made on April
3. Any new feature that you propose must be committed by then.

I suggest focusing on Python 3.2 instead.

Regards,
Martin


From floris.bruynooghe at gmail.com  Mon Mar 29 22:37:18 2010
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Mon, 29 Mar 2010 21:37:18 +0100
Subject: [Distutils] PEP 376 Status
In-Reply-To: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
Message-ID: <20100329203718.GA28933@laurie.devork>

Hi

On Thu, Mar 25, 2010 at 11:20:41AM +0100, Tarek Ziad? wrote:
> I've sent a mail after Pycon to request some comments on the work we
> have done during Pycon but I had no feedback at all :)
> 
> http://mail.python.org/pipermail/distutils-sig/2010-March/015684.html
> 
> I realize that this piece of work is quite dense, and hard to follow.
> 
> (As a reminder the draft is here:
> http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst)

This work calls for a systemwide sysconfig.cfg file which maps the
categories onto system locations.  I notice the example one contains
sections for "posix" and "posix_home" (among others), presumably the
"posix_home" one is for when using "setup.py --home".  But what about
the user site-packages directory (setup.py --user)?  Would it make
sense to have a sysconfig.cfg (or equivalent) file in the user
site-packages too?

On a tangent it seems to like --home should be deprecated in favour of
--user.  Any toughts on this?


As for the 1st point of the open issues - what about pkgutil.open()
without having to use a "setup.py develop"; here a half baked idea: If
the sys.path entry from which the current module came from does not
contain the setup.cfg metadata required can pkgutil.open() not assume
that it's a non-installed package/module and simply use the relative
path to find the resource?  Altough I can still see this getting messy
with non-inplace builds of extension modules.


Lastly has toydist's "toysetup.info" from David Cournapeau been
considered in the discussions on setup.cfg for distutils2?  It's a
pretty nice format and it actually has an implementation too.  I do
think there is value in that format to superseed the
setup.py/setup.cfg combination (there is the problem of setup.cfg now
becoming both a config file for the developer as well as a formal
description for the package distribution).  Currently it seems a lot
more verbose for tagging files under categories compared to the
proposed setup.cfg, but that might not be set in stone and I hope
David will be happy to incorporate reasonable proposals if this is
preceived to be a problem.


Regards
Floris

PS: Thanks for the work of writing up the PyCon packaging sprint!


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From ianb at colorstudy.com  Mon Mar 29 23:07:25 2010
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 29 Mar 2010 15:07:25 -0600
Subject: [Distutils] PEP 376 Status
In-Reply-To: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
Message-ID: <b654cd2e1003291407o1531d4b9x6cb57f4294afd890@mail.gmail.com>

After reading through the PEP, one thing that I'd like to see is the use of
relative filenames in RECORD.  I've used this functionality myself with pip
and Silver Lining, where I am transferring code (in its installed form)
between systems; so long as you stick to pure-Python code and have relative
filenames (as pip uses, and with some fixups of .pth files) this works
well.  Systems like App Engine also encourage this kind of behavior.
Uninstall actually becomes more interesting to me as well in this model, as
I have these packages installed for a much longer amount of time (I'm not
simply reinstalling everything on new computers).

After a bit of IRC discussion, it seems like files that are outside of
sys.prefix should not be relative (e.g., a file installed in /etc shouldn't
be ../../../../etc/package/some-file), but anything inside sys.prefix can be
relative.  This would work well with virtualenv, for instance (where most
everything is under sys.prefix, and relative files work nicely for all those
cases).

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://twitter.com/ianbicking
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100329/f762b79e/attachment.html>

From merwok at netwok.org  Mon Mar 29 23:00:47 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 29 Mar 2010 23:00:47 +0200
Subject: [Distutils] PEP 376 Status
In-Reply-To: <20100329203718.GA28933@laurie.devork>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<20100329203718.GA28933@laurie.devork>
Message-ID: <4BB114FF.6010104@netwok.org>

> On a tangent it seems to like --home should be deprecated in favour of
> --user.  Any toughts on this?

I personally like to use ~/.local as prefix, but I?m sure there are a 
lot of people used to have bin, lib and co. in their home directory. I 
think it?s clutter but everyone is entitled to their preferences, so I 
don?t think it?s feasible to deprecate --home.

Regards

From sridharr at activestate.com  Mon Mar 29 23:27:47 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 29 Mar 2010 14:27:47 -0700
Subject: [Distutils] PEP 376 Status
In-Reply-To: <4BB114FF.6010104@netwok.org>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<20100329203718.GA28933@laurie.devork>
	<4BB114FF.6010104@netwok.org>
Message-ID: <E9A69B07-98F5-460C-9656-1DEE3A1884F2@activestate.com>


On 2010-03-29, at 2:00 PM, ?ric Araujo wrote:

>> On a tangent it seems to like --home should be deprecated in favour of
>> --user.  Any toughts on this?
> 
> I personally like to use ~/.local as prefix, but I?m sure there are a lot of people used to have bin, lib and co. in their home directory. I think it?s clutter but everyone is entitled to their preferences, so I don?t think it?s feasible to deprecate --home.

Well, since PEP 370 is more than --home (adds ~/.local to sys.path automatically), I favour deprecation of --home with a message suggesting the user to set "site.USER_BASE" to his home directory.

-srid


From ziade.tarek at gmail.com  Mon Mar 29 23:42:19 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 23:42:19 +0200
Subject: [Distutils] PEP 376 Status
In-Reply-To: <1ABEF90B-4233-4935-9D26-88913A521401@activestate.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<4BAB7BCA.2090604@optimum.net>
	<20100325163551.127F43A4080@sparrow.telecommunity.com>
	<94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>
	<887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>
	<94bdd2611003290032o49f09147ha16b33d5a3b63d6c@mail.gmail.com>
	<1ABEF90B-4233-4935-9D26-88913A521401@activestate.com>
Message-ID: <94bdd2611003291442q13c4ef2cxdfb4d717878fb88e@mail.gmail.com>

On Mon, Mar 29, 2010 at 6:20 PM, Sridhar Ratnakumar
<sridharr at activestate.com> wrote:
>
> On 2010-03-29, at 12:32 AM, Tarek Ziad? wrote:
>
> On Thu, Mar 25, 2010 at 8:56 PM, Sridhar Ratnakumar
> <sridharr at activestate.com> wrote:
> [..]
>
> +1
>
> I presume sdist too, if generated with 'python setup.py sdist', will contain
>
> this .dist-info directory?
>
> I don't think so, because part of the files are generated at installation
> time.
>
> Do you have something in mind ?
>
> Yes, I read metadata of source distributions by trying to find the PKG-INFO
> files and extracting at least Name and Version from it (using filenames is
> unreliable -- eg: "latest.zip"). I thought that due to environment markers
> and such changes hinting static metadata, the source distribution will at
> least have METADATA (formerly PKG-INFO) in it. Will that be the case with
> distutuils2? I know that distutils/setuptools includes PKG-INFO.

I guess we could generate METADATA through sdist but not the other files.

I am a bit worried of having a partial .dist-info directory though, not sure why

Tarek

-- 
Tarek Ziad? | http://ziade.org

From ianb at colorstudy.com  Mon Mar 29 23:45:00 2010
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 29 Mar 2010 15:45:00 -0600
Subject: [Distutils] [Python-Dev] Bootstrap script for package
	management tool in Python 2.7 (Was: Re: At least one package
	management tool for 2.7)
In-Reply-To: <4BB0E2AD.6020407@hastings.org>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com> 
	<4BB0E2AD.6020407@hastings.org>
Message-ID: <b654cd2e1003291445w1dfcc63sa35043499613185e@mail.gmail.com>

On Mon, Mar 29, 2010 at 11:26 AM, Larry Hastings <larry at hastings.org> wrote:

> anatoly techtonik wrote:
>
>> So, there won't be any package management tool shipped with Python 2.7
>> and users will have to download and install `setuptools` manually as
>> before:
>>
>>  "search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python
>> setup.py install"
>>
>>
>> Therefore I still propose shipping bootstrap package that instruct
>> user how to download and install an actual package  management tool
>> when users tries to use it.
>>
>
> For what it's worth, Guido prototyped something similar in March of 2008,
> but his was an actual bootstrapping tool for package management:
>
>   http://mail.python.org/pipermail/python-dev/2008-March/077837.html
>
> His tool knew how to download a tar file, untar it, and run "python
> setup.py install" on it.  No version numbers, no dependency management,
> simple enough that it should be easy to get right.  Only appropriate for
> bootstrapping into a real package management tool.
>
> The thread ends with him saying "I don't have time to deal with this
> further this week", and I dunno, maybe it just fell off the radar?  I'd been
> thinking about resurrecting the discussion but I didn't have time either.
>

I would consider this bootstrap to be quite workable, though I would add
that any extra option to the bootstrap script should be passed to setup.py
install, and the download should be cached (so you can do -h and not have to
re-download the package once you figure out the extra options -- at least a
--user option is reasonable here for people without root).  Specifically
targeting this bootstrap for tools like pip and virtualenv is no problem.

I think looking around PyPI etc is kind of more than I'd bother with.  Those
things change, this bootstrap code won't change, it could cause unnecessary
future pain.  Maybe (*maybe*) it could look in
http://pypi.python.org/well-known-packages/PACKAGE_NAME and so we can have
it install a certain small number of things quickly that way -- if the URL
it looks to is targeted only for the bootstrap script itself then we don't
have to worry about compatibility problems as much.

Oh... then i can think of a half dozen other options it could take, and then
it becomes an installer.  Blech.  OK, I'd be willing to cut off the options
at --user (which I think is a minimum... maybe --prefix too), and maybe some
simple package detection so people could write "python -m boostrap
Setuptools --user" -- entirely based on some well-known URL baked into
bootstrap.py, where the URL is independent of any other service (and so is
least likely to cause future problems or ambiguities).

An advantage to this kind of bootstrapper is that as future packaging
systems are developed there's a clear way to get started with them, without
prematurely baking anything in to Python.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://twitter.com/ianbicking
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100329/af8a9e14/attachment-0001.html>

From ziade.tarek at gmail.com  Mon Mar 29 23:54:23 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 23:54:23 +0200
Subject: [Distutils] PEP 376 Status
In-Reply-To: <20100329203718.GA28933@laurie.devork>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<20100329203718.GA28933@laurie.devork>
Message-ID: <94bdd2611003291454l69470917uf8227e1e6e317b60@mail.gmail.com>

On Mon, Mar 29, 2010 at 10:37 PM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
> Hi
>
> On Thu, Mar 25, 2010 at 11:20:41AM +0100, Tarek Ziad? wrote:
>> I've sent a mail after Pycon to request some comments on the work we
>> have done during Pycon but I had no feedback at all :)
>>
>> http://mail.python.org/pipermail/distutils-sig/2010-March/015684.html
>>
>> I realize that this piece of work is quite dense, and hard to follow.
>>
>> (As a reminder the draft is here:
>> http://hg.python.org/distutils2/file/tip/docs/design/wiki.rst)
>
> This work calls for a systemwide sysconfig.cfg file which maps the
> categories onto system locations. ?I notice the example one contains
> sections for "posix" and "posix_home" (among others), presumably the
> "posix_home" one is for when using "setup.py --home".

Yes,


>But what about
> the user site-packages directory (setup.py --user)? ?Would it make
> sense to have a sysconfig.cfg (or equivalent) file in the user
> site-packages too?

What about having a user section in sysconfig.cfg ?

>
> On a tangent it seems to like --home should be deprecated in favour of
> --user. ?Any toughts on this?

Why deprecating --home ? It's a target for unix-only systems, but not
specific to a user

>
>
> As for the 1st point of the open issues - what about pkgutil.open()
> without having to use a "setup.py develop"; here a half baked idea: If
> the sys.path entry from which the current module came from does not
> contain the setup.cfg metadata required can pkgutil.open() not assume
> that it's a non-installed package/module and simply use the relative
> path to find the resource? ?Altough I can still see this getting messy
> with non-inplace builds of extension modules.

I think it's a bit what we've try to do: pkgutil.open() works with paths
in the development tree, relative to setup.py/cfg.

If its' not what you mean, can you provide examples ?

>
>
> Lastly has toydist's "toysetup.info" from David Cournapeau been
> considered in the discussions on setup.cfg for distutils2? ?It's a
> pretty nice format and it actually has an implementation too.

No. I havn't looked at it yet, I think its pretty new (like, a few
months maybe?)

> ?I do
> think there is value in that format to superseed the
> setup.py/setup.cfg combination (there is the problem of setup.cfg now
> becoming both a config file for the developer as well as a formal
> description for the package distribution). ?Currently it seems a lot
> more verbose for tagging files under categories compared to the
> proposed setup.cfg, but that might not be set in stone and I hope
> David will be happy to incorporate reasonable proposals if this is
> preceived to be a problem.

If David could participate to this discussion and present his ideas on
this, that would be great.
We could compare both syntaxes and try to build the best one.



>
>
> Regards
> Floris
>
> PS: Thanks for the work of writing up the PyCon packaging sprint!

For the wiki.rst, that's mainly other people from the sprint group
that did this summary ;)

So +1 in the thanks

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Mon Mar 29 23:55:37 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 29 Mar 2010 23:55:37 +0200
Subject: [Distutils] PEP 376 Status
In-Reply-To: <b654cd2e1003291407o1531d4b9x6cb57f4294afd890@mail.gmail.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<b654cd2e1003291407o1531d4b9x6cb57f4294afd890@mail.gmail.com>
Message-ID: <94bdd2611003291455j6fff9384p2d3eb82a9b5c694b@mail.gmail.com>

On Mon, Mar 29, 2010 at 11:07 PM, Ian Bicking <ianb at colorstudy.com> wrote:
> After reading through the PEP, one thing that I'd like to see is the use of
> relative filenames in RECORD.? I've used this functionality myself with pip
> and Silver Lining, where I am transferring code (in its installed form)
> between systems; so long as you stick to pure-Python code and have relative
> filenames (as pip uses, and with some fixups of .pth files) this works
> well.? Systems like App Engine also encourage this kind of behavior.
> Uninstall actually becomes more interesting to me as well in this model, as
> I have these packages installed for a much longer amount of time (I'm not
> simply reinstalling everything on new computers).
>
> After a bit of IRC discussion, it seems like files that are outside of
> sys.prefix should not be relative (e.g., a file installed in /etc shouldn't
> be ../../../../etc/package/some-file), but anything inside sys.prefix can be
> relative.? This would work well with virtualenv, for instance (where most
> everything is under sys.prefix, and relative files work nicely for all those
> cases).

If no one objects, I'll change it this way.

-- 
Tarek Ziad? | http://ziade.org

From tseaver at palladion.com  Tue Mar 30 00:48:30 2010
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 29 Mar 2010 18:48:30 -0400
Subject: [Distutils] PEP 376 Status
In-Reply-To: <94bdd2611003291442q13c4ef2cxdfb4d717878fb88e@mail.gmail.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>	<4BAB7BCA.2090604@optimum.net>	<20100325163551.127F43A4080@sparrow.telecommunity.com>	<94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>	<887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>	<94bdd2611003290032o49f09147ha16b33d5a3b63d6c@mail.gmail.com>	<1ABEF90B-4233-4935-9D26-88913A521401@activestate.com>
	<94bdd2611003291442q13c4ef2cxdfb4d717878fb88e@mail.gmail.com>
Message-ID: <horanv$pf7$1@dough.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? wrote:
> On Mon, Mar 29, 2010 at 6:20 PM, Sridhar Ratnakumar
> <sridharr at activestate.com> wrote:
>> On 2010-03-29, at 12:32 AM, Tarek Ziad? wrote:
>>
>> On Thu, Mar 25, 2010 at 8:56 PM, Sridhar Ratnakumar
>> <sridharr at activestate.com> wrote:
>> [..]
>>
>> +1
>>
>> I presume sdist too, if generated with 'python setup.py sdist', will contain
>>
>> this .dist-info directory?
>>
>> I don't think so, because part of the files are generated at installation
>> time.
>>
>> Do you have something in mind ?
>>
>> Yes, I read metadata of source distributions by trying to find the PKG-INFO
>> files and extracting at least Name and Version from it (using filenames is
>> unreliable -- eg: "latest.zip"). I thought that due to environment markers
>> and such changes hinting static metadata, the source distribution will at
>> least have METADATA (formerly PKG-INFO) in it. Will that be the case with
>> distutuils2? I know that distutils/setuptools includes PKG-INFO.
> 
> I guess we could generate METADATA through sdist but not the other files.
> 
> I am a bit worried of having a partial .dist-info directory though, not sure why

It seems to me that sdists and binary dists need to be introspectable in
the same way that and installed and "develop" dists are.  Shouldn't the
information needed to generate the RECORD file be present in the sdist
somehow?  E.g., the CSV file could be there, but with placeholder /
logical names for the target files?

I have real use cases for treating them all as "equal animals":

 - http://packages.python.org/pkginfo

 - http://packages.python.org/compoze



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuxLjkACgkQ+gerLs4ltQ7IQACdEYme7rVRbzSgYF1tQLaHsgFY
XCEAn18ur5U5H08hLAdPTaQ1M7UmEhOH
=OleV
-----END PGP SIGNATURE-----


From ziade.tarek at gmail.com  Tue Mar 30 01:02:29 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 30 Mar 2010 01:02:29 +0200
Subject: [Distutils] PEP 376 Status
In-Reply-To: <horanv$pf7$1@dough.gmane.org>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<4BAB7BCA.2090604@optimum.net>
	<20100325163551.127F43A4080@sparrow.telecommunity.com>
	<94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>
	<887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>
	<94bdd2611003290032o49f09147ha16b33d5a3b63d6c@mail.gmail.com>
	<1ABEF90B-4233-4935-9D26-88913A521401@activestate.com>
	<94bdd2611003291442q13c4ef2cxdfb4d717878fb88e@mail.gmail.com>
	<horanv$pf7$1@dough.gmane.org>
Message-ID: <94bdd2611003291602x58668ef0i3532fd3e2adfcc@mail.gmail.com>

[..]
>> I am a bit worried of having a partial .dist-info directory though, not sure why
>
> It seems to me that sdists and binary dists need to be introspectable in
> the same way that and installed and "develop" dists are. ?Shouldn't the
> information needed to generate the RECORD file be present in the sdist
> somehow? ?E.g., the CSV file could be there, but with placeholder /
> logical names for the target files?

For a binary distribution, the file will be there since a bdist does
an install call in a local root,

For the sdist, I think that's basically heading to the work we have
started at Pycon : a list of files
with expandable variables.  The variables values will be taken from
the global sysconfig.cfg file, as described in wiki.rst.

We said during Pycon that this could be another file alongside RECORD,
that would be created by reading the (future) [resources] and [files]
sections in setup.cfg for example.


> I have real use cases for treating them all as "equal animals":
>
> ?- http://packages.python.org/pkginfo
>
> ?- http://packages.python.org/compoze

Yes. OS packagers have similar use cases



-- 
Tarek Ziad? | http://ziade.org

From greg.ewing at canterbury.ac.nz  Tue Mar 30 01:53:17 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 30 Mar 2010 11:53:17 +1200
Subject: [Distutils] Bootstrap script for package management tool
 in	Python 2.7 (Was: Re: [Python-Dev] At least one package	management tool
 for 2.7)
In-Reply-To: <d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
	<94bdd2611003290055k7daa167ewdf7e7226fcb2353f@mail.gmail.com>
	<d34314101003290202t702fd978q9d3fe2caf5217c6d@mail.gmail.com>
	<94bdd2611003290215s72ea681dp246505b8894695@mail.gmail.com>
	<d34314101003290645if3235c4g9bc068165d0eac05@mail.gmail.com>
Message-ID: <4BB13D6D.30706@canterbury.ac.nz>

anatoly techtonik wrote:

> Let's refer to original user story:
> ...
> "I execute `easy_install something` as said in installation manual,
> but nothing/error happens."

Which installation manual did the user see that in? It can't
be anything that came with Python, because easy_install is
not a standard part of Python.

If a package is telling the user to install it with a
non-standard installation tool, without explaining this fact
and how to get the tool, then the package's documentation
is lacking.

-- 
Greg

From greg.ewing at canterbury.ac.nz  Tue Mar 30 02:00:50 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 30 Mar 2010 12:00:50 +1200
Subject: [Distutils] FAQ (was: Re: Bootstrap script for
 package	management tool in Python 2.7)
In-Reply-To: <94bdd2611003290746v9004f9o457051abab0464b7@mail.gmail.com>
References: <d34314101003290741y203afb7fhae24213a7bdce2ef@mail.gmail.com>
	<94bdd2611003290746v9004f9o457051abab0464b7@mail.gmail.com>
Message-ID: <4BB13F32.4030804@canterbury.ac.nz>

Tarek Ziad? wrote:

> For me a FAQ is a list of questions. We add a new question everytime someone
> ask it and it doesn't exists.

The point is that the "FA" in "FAQ" stand for *frequently
asked*.

One can debate how frequent is necessary to be placed in
this category, but a question that has only been asked once
can hardly be called "frequent" by any measure.

(Yes, this is pedantic -- lists of answers to questions are
always useful regardless of frequency. But calling them
all FAQs is technically a misnomer.)

-- 
Greg

From fuzzyman at gmail.com  Tue Mar 30 02:06:18 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Tue, 30 Mar 2010 01:06:18 +0100
Subject: [Distutils] FAQ (was: Re: Bootstrap script for package
	management tool in Python 2.7)
In-Reply-To: <4BB13F32.4030804@canterbury.ac.nz>
References: <d34314101003290741y203afb7fhae24213a7bdce2ef@mail.gmail.com>
	<94bdd2611003290746v9004f9o457051abab0464b7@mail.gmail.com>
	<4BB13F32.4030804@canterbury.ac.nz>
Message-ID: <6f4025011003291706k28da794s71458a2fc20c34a@mail.gmail.com>

On 30 March 2010 01:00, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> Tarek Ziad? wrote:
>
>  For me a FAQ is a list of questions. We add a new question everytime
>> someone
>> ask it and it doesn't exists.
>>
>
> The point is that the "FA" in "FAQ" stand for *frequently
> asked*.
>
> One can debate how frequent is necessary to be placed in
> this category, but a question that has only been asked once
> can hardly be called "frequent" by any measure.
>

However the point of using established terminology is that everyone (or some
worthwhile subset thereof) immediately knows what to expect.

Michael



>
> (Yes, this is pedantic -- lists of answers to questions are
> always useful regardless of frequency. But calling them
> all FAQs is technically a misnomer.)
>
> --
> Greg
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100330/8f6da0e4/attachment.html>

From martin.raspaud at smhi.se  Tue Mar 30 07:26:36 2010
From: martin.raspaud at smhi.se (Martin Raspaud)
Date: Tue, 30 Mar 2010 07:26:36 +0200
Subject: [Distutils] executable option in buildout
Message-ID: <4BB18B8C.50205@smhi.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I just wrote a small recipe for buildout that installs an egg from its develop
version and tarballs it.
So far, so good, I got it to work fine with a few example packages.

Now I got a problem when trying to use the "executable" option in the
buildout.cfg file: it seems to have no effect.
The recipe runs with the default python from the system (2.5) not the one I
supply in the executable option (2.4)

I attach my buildout.cfg and the recipe.

Am I doing something wrong ?

Thanks,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLsYuLAAoJEBdvyODiyJI4pJAH/R6SRFprxS6R1maJ7blyEhtM
leJaoYdTwPpFTqLiEUFz/GvWwr6Up1yxyIinxl7SY8kw7wKd80244MHJVke2Vjf3
nim2IxyCC/E6+j4AE+vQkYx/G5nTJSFHWUd4I1k8OR6iuYuEF2WLWI9m0TBgPe6d
JaHzI+LO8FTduDp4JqPMeAg4KLI8pykhSOb4ikkBbbQXp0P99w8wHfbowHongLX2
HRECWofuzjUmv7swIOQ/+/MRlbzd2QwBVZFeXrbABGxx1GQCNpOVqjvVTAUkaBf+
79N55/LBbtVnvGH7wf6cLvZSHawDxF9XQ5OcXi1nHZD5jQ9F0l8koKq8cIJXSgc=
=v3Ew
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: buildout.cfg
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100330/8e0b2fc8/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: smhi_deploy.py
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100330/8e0b2fc8/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildout.cfg.sig
Type: application/octet-stream
Size: 287 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100330/8e0b2fc8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smhi_deploy.py.sig
Type: application/octet-stream
Size: 287 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100330/8e0b2fc8/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_raspaud.vcf
Type: text/x-vcard
Size: 259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100330/8e0b2fc8/attachment.vcf>

From cournape at gmail.com  Tue Mar 30 09:59:49 2010
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 30 Mar 2010 16:59:49 +0900
Subject: [Distutils] PEP 376 Status
In-Reply-To: <20100329203718.GA28933@laurie.devork>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<20100329203718.GA28933@laurie.devork>
Message-ID: <5b8d13221003300059k693346fbt3848916c61e9a15e@mail.gmail.com>

On Tue, Mar 30, 2010 at 5:37 AM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:

> This work calls for a systemwide sysconfig.cfg file which maps the
> categories onto system locations. ?I notice the example one contains
> sections for "posix" and "posix_home" (among others), presumably the
> "posix_home" one is for when using "setup.py --home". ?But what about
> the user site-packages directory (setup.py --user)? ?Would it make
> sense to have a sysconfig.cfg (or equivalent) file in the user
> site-packages too?

I am not sure what you mean but systemwide sysconfig. Do you mean to
override defaults ?

Concerning toydist, the scheme is as simple as I could make it. First,
toydist has an internal dict which copies autoconf:

scheme = {
        'prefix': '/usr/local',
        'eprefix': '$prefix',
        'bindir': '$eprefix/bin',
        'sbindir': '$eprefix/sbin',
        ....
}

Then, the build command of the command line interface to toydist
produces a manifest file which produces the list of files to be
installed, classified category-wise (python files, extensions,
bytecode, etc...). Each category has one installation path attached to
it (which are *not* resolved at that point, i.e. the values still
contain the $variables form). The $variables are resolved at *install*
time: this enables production of both "normal" installation and
eggs/wininst/etc... from the same manifest file, as the installation
path is resolved by the corresponding install command.

With this system, I can also support the FHS-compliant scheme (default
on unix), the Mac OS X-way on mac os X, the windows way on windows,
and --user/--prefix options without changing any of the logic.

This is also quite flexible from a user POV, because toydist has the
notion of datafile sections, which can have an arbitrary installation
path attached to it (and toydist allows the creation of new $path
variable), and can be itself referenced as a $path variable.


> Lastly has toydist's "toysetup.info" from David Cournapeau been
> considered in the discussions on setup.cfg for distutils2? ?It's a
> pretty nice format and it actually has an implementation too.

Note that most of the syntax is stolen from cabal, so I don't deserve
the credit. The implementation still has issues, though:
 - there is no support for Unicode (but this should not be too
difficult to solve, mostly a matter of tweaking a few regex in the
lexer)
 - the parser uses PLY to define the lexer and grammar
 - it is relatively slow

I am sure people familiar with parsing algos can come up with
something much better here - although PLY is quite small as a
dependency.

There is also experimental support to automatically convert setup.py
to the format (it cannot be reliable because of inherent distutils
fragility, but it can already convert reasonable packages such as
virtualenv, Jinja2 or sphinx).

>?Currently it seems a lot
> more verbose for tagging files under categories compared to the
> proposed setup.cfg

I am not sure to understand what you are referring to ? Do you mean this:

DataFiles: mandoc
    SourceDir: doc/man
    TargetDir: $manpath
    Files: man1/foo1, man3/foo3

I would be glad to hear suggestion on a better syntax, but note that
both SourceDir and TargetDir are necessary to support all the features
I want to (in particular nobase install mode as available in
automake).

> but that might not be set in stone and I hope
> David will be happy to incorporate reasonable proposals if this is
> preceived to be a problem.

Toydist is completely experimental at that point, and anything subject
to change - as suggested by its name, it is more a playground to
experiment things than a real tool (although I certainly intend to
make a real alternative to distutils/setuptools from it in the
future).

David

From cournape at gmail.com  Tue Mar 30 10:13:04 2010
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 30 Mar 2010 17:13:04 +0900
Subject: [Distutils] PEP 376 Status
In-Reply-To: <horanv$pf7$1@dough.gmane.org>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<4BAB7BCA.2090604@optimum.net>
	<20100325163551.127F43A4080@sparrow.telecommunity.com>
	<94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>
	<887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>
	<94bdd2611003290032o49f09147ha16b33d5a3b63d6c@mail.gmail.com>
	<1ABEF90B-4233-4935-9D26-88913A521401@activestate.com>
	<94bdd2611003291442q13c4ef2cxdfb4d717878fb88e@mail.gmail.com>
	<horanv$pf7$1@dough.gmane.org>
Message-ID: <5b8d13221003300113o56c5d6ecmd2d71bb0460c2cdb@mail.gmail.com>

On Tue, Mar 30, 2010 at 7:48 AM, Tres Seaver <tseaver at palladion.com> wrote:

> It seems to me that sdists and binary dists need to be introspectable in
> the same way that and installed and "develop" dists are. ?Shouldn't the
> information needed to generate the RECORD file be present in the sdist
> somehow? ?E.g., the CSV file could be there, but with placeholder /
> logical names for the target files?

I would strongly suggest at looking at existing projects which do the
exact same thing before inventing something from scratch. For example,
cabal has the notion of Installed Package Info, which is produced at
build time and shipped in binaries (and somewhere at install time),
for this exact purpose.

The syntax does not matter, but the key points are:
 - any installer can be regenerated from this manifest (+ the built
files of course)
 - it contains everything necessary to index the corresponding package
when installed (when installed, the path variables should be resolved
to the actual variables)
 - it should be reasonably fast to parse because most packagers will
need to deal with those  quite extensively (although one could imagine
putting this info in a db to speed things up).

FWIW, I used to use a custom format for toydist, but I am now
converting to a simple ConfigParser-like format, which will look like:

[meta]
name = Sphinx
# All the PKG-INFO metadata here
....
[variables]
# All path variables, + a few toydist specific stuff
prefix = some_path
site_packages = $libdir/$py_version/site-packages
...

[file:pythonfiles:library]
source_dir = build/lib.linux-2.6/
target_dir = $sitedir
files = .....

David

From simon at ikanobori.jp  Tue Mar 30 15:19:58 2010
From: simon at ikanobori.jp (Simon de Vlieger)
Date: Tue, 30 Mar 2010 15:19:58 +0200
Subject: [Distutils] A PyPi question
In-Reply-To: <5b8d13221003300113o56c5d6ecmd2d71bb0460c2cdb@mail.gmail.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<4BAB7BCA.2090604@optimum.net>
	<20100325163551.127F43A4080@sparrow.telecommunity.com>
	<94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>
	<887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>
	<94bdd2611003290032o49f09147ha16b33d5a3b63d6c@mail.gmail.com>
	<1ABEF90B-4233-4935-9D26-88913A521401@activestate.com>
	<94bdd2611003291442q13c4ef2cxdfb4d717878fb88e@mail.gmail.com>
	<horanv$pf7$1@dough.gmane.org>
	<5b8d13221003300113o56c5d6ecmd2d71bb0460c2cdb@mail.gmail.com>
Message-ID: <82532999-788B-422F-BB07-A145FD06582A@ikanobori.jp>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear all,

I am not sure if this is the correct mailinglist to address my  
question to but it was the closest thing I could find (I see a few  
names from the PyPi-commits mailing list in the archives here). If  
this is not the correct place please let me know so I can post my  
question to the correct mailing list.

The XMLRPC API documentation for PyPi at http://wiki.python.org/moin/PyPiXmlRpc 
  contains a 'downloads' key in the example. However in the  
documentation below it is missing and my own tries at the API confirm  
this.

Now I would very much like to have access to the data (especially the  
download count). Is there any possibility of these values returning?

Regards,

Simon de Vlieger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQIcBAEBAgAGBQJLsfp/AAoJEBBSHP7i+JXfeaMQAKPRKalf/kiFXzi0yCuyKM9Z
VJzHdtB5lE3F6EyvWj9iVML1in7HNnO1yvBRfwVTT9QWLyqrn62MFz/wd05NGP6l
8WVGJXNGvne3evUdDAj4aHSf6ZkAtO14MMjjW49gi52MDK9Gncdj0xxH8xG9VCaP
MAE5EJf7EPJZ0BR3j6ta4L40mTJKwJFFCLTq6OrxRdcx67ua0BUGtfkyCI4ucakv
yzq9vP4mnx7riV2cLkEY7IR5nkl2GzlC8iPjP9ORgeDRxvy1qYHcOnyn5OsNuv79
zs2Exq0wGXSa3moPMS+q05X+zrmAf5sSR8It8/qeVaSKehdAlP9LQfFpIYF8J7kE
w7clasPhWyH1Q4v24lvCBblR8LKkDSBNFEl14rY2VUIFvM9onmq1KBuQJc1Gl5Fl
WAnQK19MpaqZgEBdHXNUtIcuygm036hQOChQVhXYqSgzPARp45Gh9AhfU+Wjtt5V
v+FFrHSOs9LBWyJWoahIYSj7JlcKNPvsjfB/F4PeQSJaRFhbgD2arYOD11r//p60
SUvszUbTBvcLr0cQ6HqQCymhOOTC/baG9TU4ikbAoYwoD6FEPsVxe6VEGEBwXiUI
eY0bEWZ3nwUm6dgYITDvLebI4APIQxMIlzgVkuCZeyoil5wFSFO9e082Qh0hemRP
yn/0APlqzM1lxOPQx3Tv
=UdMs
-----END PGP SIGNATURE-----

From ziade.tarek at gmail.com  Tue Mar 30 16:09:17 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 30 Mar 2010 16:09:17 +0200
Subject: [Distutils] A PyPi question
In-Reply-To: <82532999-788B-422F-BB07-A145FD06582A@ikanobori.jp>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<20100325163551.127F43A4080@sparrow.telecommunity.com>
	<94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>
	<887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>
	<94bdd2611003290032o49f09147ha16b33d5a3b63d6c@mail.gmail.com>
	<1ABEF90B-4233-4935-9D26-88913A521401@activestate.com>
	<94bdd2611003291442q13c4ef2cxdfb4d717878fb88e@mail.gmail.com>
	<horanv$pf7$1@dough.gmane.org>
	<5b8d13221003300113o56c5d6ecmd2d71bb0460c2cdb@mail.gmail.com>
	<82532999-788B-422F-BB07-A145FD06582A@ikanobori.jp>
Message-ID: <94bdd2611003300709y195a7a71i8ea1c499ca49b363@mail.gmail.com>

Hi Simon,

The right list is the Catalog-SIG

Regards,
Tarek

From simon at ikanobori.jp  Tue Mar 30 16:21:11 2010
From: simon at ikanobori.jp (Simon de Vlieger)
Date: Tue, 30 Mar 2010 16:21:11 +0200
Subject: [Distutils] A PyPi question
In-Reply-To: <94bdd2611003300709y195a7a71i8ea1c499ca49b363@mail.gmail.com>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>
	<20100325163551.127F43A4080@sparrow.telecommunity.com>
	<94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>
	<887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>
	<94bdd2611003290032o49f09147ha16b33d5a3b63d6c@mail.gmail.com>
	<1ABEF90B-4233-4935-9D26-88913A521401@activestate.com>
	<94bdd2611003291442q13c4ef2cxdfb4d717878fb88e@mail.gmail.com>
	<horanv$pf7$1@dough.gmane.org>
	<5b8d13221003300113o56c5d6ecmd2d71bb0460c2cdb@mail.gmail.com>
	<82532999-788B-422F-BB07-A145FD06582A@ikanobori.jp>
	<94bdd2611003300709y195a7a71i8ea1c499ca49b363@mail.gmail.com>
Message-ID: <A623EA12-333E-4EBF-9324-ED9971B81BE4@ikanobori.jp>

Tarek,

Thanks for the pointer. I will post my question there.

Regards,

Simon de Vlieger

On 30 mrt 2010, at 16:09, Tarek Ziad? wrote:

> Hi Simon,
>
> The right list is the Catalog-SIG
>
> Regards,
> Tarek


From martin at v.loewis.de  Tue Mar 30 19:21:33 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 30 Mar 2010 19:21:33 +0200
Subject: [Distutils] A PyPi question
In-Reply-To: <82532999-788B-422F-BB07-A145FD06582A@ikanobori.jp>
References: <94bdd2611003250320i720ba93epe7a37d5cc2ffaf34@mail.gmail.com>	<4BAB7BCA.2090604@optimum.net>	<20100325163551.127F43A4080@sparrow.telecommunity.com>	<94bdd2611003251021w42f60dbcq8ea3bbfb4716a2a8@mail.gmail.com>	<887678F4-EC0F-4BC7-B112-ED3DC01E0939@activestate.com>	<94bdd2611003290032o49f09147ha16b33d5a3b63d6c@mail.gmail.com>	<1ABEF90B-4233-4935-9D26-88913A521401@activestate.com>	<94bdd2611003291442q13c4ef2cxdfb4d717878fb88e@mail.gmail.com>	<horanv$pf7$1@dough.gmane.org>	<5b8d13221003300113o56c5d6ecmd2d71bb0460c2cdb@mail.gmail.com>
	<82532999-788B-422F-BB07-A145FD06582A@ikanobori.jp>
Message-ID: <4BB2331D.1030203@v.loewis.de>


> I am not sure if this is the correct mailinglist to address my question
> to but it was the closest thing I could find (I see a few names from the
> PyPi-commits mailing list in the archives here). If this is not the
> correct place please let me know so I can post my question to the
> correct mailing list.

catalog-sig would be a better place for discussion.

> Now I would very much like to have access to the data (especially the
> download count). Is there any possibility of these values returning?

Please submit a feature request to sf.net/projects/pypi.

Regards,
Martin

From ziade.tarek at gmail.com  Tue Mar 30 23:06:25 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 30 Mar 2010 23:06:25 +0200
Subject: [Distutils] RECORD format in PEP 376
In-Reply-To: <94bdd2611003290107s779bd82fyc70363578acfe148@mail.gmail.com>
References: <94bdd2611003290107s779bd82fyc70363578acfe148@mail.gmail.com>
Message-ID: <94bdd2611003301406k5d6d5eb1p574dbf5a5de06c31@mail.gmail.com>

On Mon, Mar 29, 2010 at 10:07 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> Hello,
>
> I'd like to make the RECORD file dead simple for PEP 376, and remove
> all the relocatable work we've started in it, since it'll go in a
> second
> file. This would be done in a second phase, with the work done at Pycon.

Ok, Iv'e done this, according to the feedback in the other thread:

paths are now relative to sys.prefix, and absolute if not under sys.prefix.


Anything else about PEP 376 before I propose it in python-dev ? :)

Regards,
Tarek

-- 
Tarek Ziad? | http://ziade.org

From rene at fleschenberg.net  Wed Mar 31 00:08:44 2010
From: rene at fleschenberg.net (=?iso-8859-1?q?Ren=E9_Fleschenberg?=)
Date: Wed, 31 Mar 2010 00:08:44 +0200
Subject: [Distutils] zc.buildout: bootstrap.py script
Message-ID: <201003310008.50477.rene@fleschenberg.net>

Hi,

The code in bootstrap.py doesn't use the if __name__ == "__main__" idiom. 
This can lead to funny behaviour if it is imported for some reason (I 
stumbled upon this in conjunction with nose).

Is there a reason for not checking for __name__ == "__main__", or should 
this be changed?

-- 
Ren? Fleschenberg

Am Stadtgarten 28, 45276 Essen, Germany
Phone: +49 1577 170 7363
E-Mail: rene at fleschenberg.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100331/f06f9f28/attachment.pgp>

From ziade.tarek at gmail.com  Wed Mar 31 00:50:33 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 31 Mar 2010 00:50:33 +0200
Subject: [Distutils] zc.buildout: bootstrap.py script
In-Reply-To: <201003310008.50477.rene@fleschenberg.net>
References: <201003310008.50477.rene@fleschenberg.net>
Message-ID: <94bdd2611003301550s565f7200j87d08c6360c41242@mail.gmail.com>

On Wed, Mar 31, 2010 at 12:08 AM, Ren? Fleschenberg
<rene at fleschenberg.net> wrote:
> Hi,
>
> The code in bootstrap.py doesn't use the if __name__ == "__main__" idiom.
> This can lead to funny behaviour if it is imported for some reason (I
> stumbled upon this in conjunction with nose).
>
> Is there a reason for not checking for __name__ == "__main__", or should
> this be changed?

I don't see any goog reason not to have a __main__ section,

+1 for changing this


>
> --
> Ren? Fleschenberg
>
> Am Stadtgarten 28, 45276 Essen, Germany
> Phone: +49 1577 170 7363
> E-Mail: rene at fleschenberg.net
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>



-- 
Tarek Ziad? | http://ziade.org

From sridharr at activestate.com  Wed Mar 31 01:34:37 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Tue, 30 Mar 2010 16:34:37 -0700
Subject: [Distutils] RECORD format in PEP 376
In-Reply-To: <94bdd2611003301406k5d6d5eb1p574dbf5a5de06c31@mail.gmail.com>
References: <94bdd2611003290107s779bd82fyc70363578acfe148@mail.gmail.com>
	<94bdd2611003301406k5d6d5eb1p574dbf5a5de06c31@mail.gmail.com>
Message-ID: <743DDBEE-C286-485E-BE6A-319DE3AAFCA7@activestate.com>


On 2010-03-30, at 2:06 PM, Tarek Ziad? wrote:

> On Mon, Mar 29, 2010 at 10:07 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> Hello,
>> 
>> I'd like to make the RECORD file dead simple for PEP 376, and remove
>> all the relocatable work we've started in it, since it'll go in a
>> second
>> file. This would be done in a second phase, with the work done at Pycon.
> 
> Ok, Iv'e done this, according to the feedback in the other thread:
> 
> paths are now relative to sys.prefix,

Ok.

> and absolute if not under sys.prefix.

Sorry, I'm a little confused. So "/etc/myapp.conf" can be in RECORD? How would the second file (to be done in a second phase) be able to relocate this absolute path?

-srid


From ziade.tarek at gmail.com  Wed Mar 31 01:48:00 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 31 Mar 2010 01:48:00 +0200
Subject: [Distutils] RECORD format in PEP 376
In-Reply-To: <743DDBEE-C286-485E-BE6A-319DE3AAFCA7@activestate.com>
References: <94bdd2611003290107s779bd82fyc70363578acfe148@mail.gmail.com>
	<94bdd2611003301406k5d6d5eb1p574dbf5a5de06c31@mail.gmail.com>
	<743DDBEE-C286-485E-BE6A-319DE3AAFCA7@activestate.com>
Message-ID: <94bdd2611003301648u61a26112i4d571af214768c63@mail.gmail.com>

On Wed, Mar 31, 2010 at 1:34 AM, Sridhar Ratnakumar
<sridharr at activestate.com> wrote:
>
> On 2010-03-30, at 2:06 PM, Tarek Ziad? wrote:
>
>> On Mon, Mar 29, 2010 at 10:07 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>> Hello,
>>>
>>> I'd like to make the RECORD file dead simple for PEP 376, and remove
>>> all the relocatable work we've started in it, since it'll go in a
>>> second
>>> file. This would be done in a second phase, with the work done at Pycon.
>>
>> Ok, Iv'e done this, according to the feedback in the other thread:
>>
>> paths are now relative to sys.prefix,
>
> Ok.
>
>> and absolute if not under sys.prefix.
>
> Sorry, I'm a little confused. So "/etc/myapp.conf" can be in RECORD? How would the second file (to be done in a second phase) be able to relocate this absolute path?

By having another file pretty similar to the sections we want to add
in setup.cfg, in the dist-info directory, with expandable variables.
Then re-created the RECORD file using the new relocation

(see wiki.cfg for more details)

> -srid
>
>



-- 
Tarek Ziad? | http://ziade.org

From larry at hastings.org  Mon Mar 29 19:26:05 2010
From: larry at hastings.org (Larry Hastings)
Date: Mon, 29 Mar 2010 10:26:05 -0700
Subject: [Distutils] [Python-Dev] Bootstrap script for package
 management tool in Python 2.7 (Was: Re: At least one package management
 tool for 2.7)
In-Reply-To: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
References: <d34314101003290030g6623531er4a70f911b1423767@mail.gmail.com>
Message-ID: <4BB0E2AD.6020407@hastings.org>

anatoly techtonik wrote:
> So, there won't be any package management tool shipped with Python 2.7
> and users will have to download and install `setuptools` manually as
> before:
>
>   "search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python
> setup.py install"
>
>
> Therefore I still propose shipping bootstrap package that instruct
> user how to download and install an actual package  management tool
> when users tries to use it.

For what it's worth, Guido prototyped something similar in March of 
2008, but his was an actual bootstrapping tool for package management:

    http://mail.python.org/pipermail/python-dev/2008-March/077837.html

His tool knew how to download a tar file, untar it, and run "python 
setup.py install" on it.  No version numbers, no dependency management, 
simple enough that it should be easy to get right.  Only appropriate for 
bootstrapping into a real package management tool.

The thread ends with him saying "I don't have time to deal with this 
further this week", and I dunno, maybe it just fell off the radar?  I'd 
been thinking about resurrecting the discussion but I didn't have time 
either.

I fear it is too late for 2.7,


//larry//

From rene at fleschenberg.net  Mon Mar 29 19:20:20 2010
From: rene at fleschenberg.net (=?iso-8859-1?q?Ren=E9_Fleschenberg?=)
Date: Mon, 29 Mar 2010 19:20:20 +0200
Subject: [Distutils] zc.buildout: bootstrap.py script
Message-ID: <201003291920.25546.rene@fleschenberg.net>

Hi,

The code in bootstrap.py doesn't use the if __name__ == "__main__" idiom. 
This can lead to funny behaviour if it is imported for some reason (I 
stumbled upon this in conjunction with nose).

Is there a reason for not checking for __name__ == "__main__", or should 
this be changed?

-- 
Ren? Fleschenberg

Am Stadtgarten 28, 45276 Essen, Germany
Phone: +49 1577 170 7363
E-Mail: rene at fleschenberg.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100329/be4a2a1e/attachment.pgp>