From jaraco at jaraco.com  Wed Sep  1 13:53:29 2010
From: jaraco at jaraco.com (Jason R. Coombs)
Date: Wed, 1 Sep 2010 04:53:29 -0700
Subject: [Distutils] Need for ability to limit dependencies similar to
	'extras'
Message-ID: <12C7AB425F0DD546B6049311F827C74E0974FDA4A1@VA3DIAXVS141.RED001.local>

We're using setuptools for packaging our Python projects. Several of our 
projects have a server/client aspect to them, where the server is a 
full-fledged service with a lot of dependencies and the client is just an API 
for accessing the server, probably with just a few dependencies.  We want a 
way to install the package with or without these dependencies. With the 
current implementation of setuptools, I believe we have two choices.

1) Refactor the package into three packages: project_server, project_client, 
and project_common. Project_server would then contain the additional 
dependencies.
2) Use the extras_require for the server facet of the project. So 
"easy_install project" installs the common dependencies and "easy_install 
project[server]" installs the additional dependencies.

The second option is what we're using, but the [server] facet is the most 
common usage. We would prefer instead to have a way to "easy_install 
project[client]" which would _limit_ the dependencies needed, and 
"easy_install project" would install the full set of dependencies.

Has anyone heard of a plugin which does this? Is it even possible that a 
plugin could trim out dependencies?

I can see how there are at least three approaches to this plugin:

1) Continue to define the additional requirements as extras, and then have 
another parameter that selects the extras implicitly unless 'client' is 
specified. I'm thinking of something like a "requires_extras_unless = 
{'client': 'server'}"
2) Have another parameter which re-lists those requirements which are not 
required when project[client] is used.
3) Extend extras_require to allow keys such as '-client' or '!client', whose 
values are only required if client is not specified.

I can forsee how any of these approaches could get messy and break lots of 
assumptions about how extras and project dependencies are used. Any thoughts?

Regards,
Jason

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6448 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100901/d98a2f2a/attachment.bin>

From gotcha at bubblenet.be  Thu Sep  2 12:39:12 2010
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Thu, 02 Sep 2010 12:39:12 +0200
Subject: [Distutils] different python versions in one buildout?!
In-Reply-To: <AANLkTimx5Edv17G-nq-PXkasP4r0BE3BGJ4NZSNf-MV0@mail.gmail.com>
References: <E025916A-57C9-437B-8C2C-4A0EA0AE4D16@canonical.com>	<i50an3$96j$1@dough.gmane.org>
	<i50l08$ocb$1@dough.gmane.org>	<C50784F5-855F-4FC4-878A-7CB9008A6591@canonical.com>	<i52p1e$dur$1@dough.gmane.org>	<19BF88C4-9AE3-46B0-BBCE-6115F4A4C625@canonical.com>	<4C777604.6050509@vanrees.org>	<94B2F054-FA29-430B-94B1-AAB2B04F748F@canonical.com>	<4C7BE505.5020208@simplistix.co.uk>
	<AANLkTimx5Edv17G-nq-PXkasP4r0BE3BGJ4NZSNf-MV0@mail.gmail.com>
Message-ID: <i5nusg$1hp$1@dough.gmane.org>

Le 30/08/10 19:27, Jim Fulton a ?crit :
> On Mon, Aug 30, 2010 at 1:06 PM, Chris Withers<chris at simplistix.co.uk>  wrote:
>> Gary Poster wrote:
>>>>
>>>> It's not like I want my system matplotlib in one part and a locally
>>>> failing-horribly buildout-installed matplotlib in another part.
>>>
>>> No, but single buildouts are used to install different sections with
>>> entirely different requirements, including different Python versions.
>>
>> This feels like needless complexity to me.
>
> This is a requirement we had here at ZC.  It wasn't
> needless.
>
>> If a different python is needed, it should be in its own buildout.
>> If you need to bundle a bunch of buildouts together because of this, use a
>> recipe that runs "sub buildouts" in a separate process...
>
> It's possible that this would be a better approach.  It's true that
> supporting multiple Python interpreters is a pain.  I don't have this
> need atm, so I'm not motivated to try your solution. :)
>
> I wonder what other people think.  Does anyone else have current
> need to deal with multiple Python versions in the same buildout?
>
> Jim

I am developing vimpdb which I obviously want to be compatible with 
multiple python versions.

I was planning to write  a single buildout to build the various testrunners.

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be


From a.cavallo at cavallinux.eu  Thu Sep  2 13:55:01 2010
From: a.cavallo at cavallinux.eu (a.cavallo at cavallinux.eu)
Date: Thu, 2 Sep 2010 13:55:01 +0200
Subject: [Distutils] different python versions in one buildout?!
Message-ID: <30523.1283428501@cavallinux.eu>


Maybe this project can be a reasonable starting point:

http://pyvm.sf.net

It works for the python 2.7x trunk but the same engine can be adapted to
different python versions with slight modifications.

Basically it will let you use different python version builds at the same-ish time,
side by side, so you can test your code vs different python revisions.


Regards
Antonio

 On Thu 02/09/10 12:39, "Godefroid Chapelle" gotcha at bubblenet.be wrote:
> Le 30/08/10 19:27, Jim Fulton a ?crit :
> > On Mon, Aug 30, 2010 at 1:06 PM, Chris Withers<chris@
> simplistix.co.uk>  wrote:
>> Gary Poster wrote:
> >>>>
> >>>> It's not like I want my system
> matplotlib in one part and a locally
>>>> failing-horribly buildout-installed
> matplotlib in another part.
>>>
> >>> No, but single buildouts are used to install
> different sections with
>>> entirely different requirements, including
> different Python versions.
>>
> >> This feels like needless complexity to
> me.
>
> > This is a requirement we had here at ZC.  It
> wasn't
> needless.
> >
> >> If a different python is needed, it should be in
> its own buildout.
>> If you need to bundle a bunch of buildouts
> together because of this, use a
>> recipe that runs "sub buildouts" in a separate
> process...
>
> > It's possible that this would be a better approach. 
> It's true that
> supporting multiple Python interpreters is a pain. 
> I don't have this
> need atm, so I'm not motivated to try your solution.
> :)
>
> > I wonder what other people think.  Does anyone else
> have current
> need to deal with multiple Python versions in the
> same buildout?
>
> > Jim
> 
> I am developing vimpdb which I obviously want to be compatible with 
> multiple python versions.
> 
> I was planning to write  a single buildout to build the various
> testrunners.
> -- 
> Godefroid Chapelle (aka __gotcha) http://bubblenet.be
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
> 
> 


From jim at zope.com  Thu Sep  2 14:53:07 2010
From: jim at zope.com (Jim Fulton)
Date: Thu, 2 Sep 2010 08:53:07 -0400
Subject: [Distutils] different python versions in one buildout?!
In-Reply-To: <i5nusg$1hp$1@dough.gmane.org>
References: <E025916A-57C9-437B-8C2C-4A0EA0AE4D16@canonical.com>
	<i50an3$96j$1@dough.gmane.org> <i50l08$ocb$1@dough.gmane.org>
	<C50784F5-855F-4FC4-878A-7CB9008A6591@canonical.com>
	<i52p1e$dur$1@dough.gmane.org>
	<19BF88C4-9AE3-46B0-BBCE-6115F4A4C625@canonical.com>
	<4C777604.6050509@vanrees.org>
	<94B2F054-FA29-430B-94B1-AAB2B04F748F@canonical.com>
	<4C7BE505.5020208@simplistix.co.uk>
	<AANLkTimx5Edv17G-nq-PXkasP4r0BE3BGJ4NZSNf-MV0@mail.gmail.com>
	<i5nusg$1hp$1@dough.gmane.org>
Message-ID: <AANLkTik9ZKxJdzRho_bCA_ikeTSpec671zaB2quCgL1N@mail.gmail.com>

On Thu, Sep 2, 2010 at 6:39 AM, Godefroid Chapelle <gotcha at bubblenet.be> wrote:
> Le 30/08/10 19:27, Jim Fulton a ?crit :
>>
>> On Mon, Aug 30, 2010 at 1:06 PM, Chris Withers<chris at simplistix.co.uk>
>> ?wrote:
>>>
>>> Gary Poster wrote:
>>>>>
>>>>> It's not like I want my system matplotlib in one part and a locally
>>>>> failing-horribly buildout-installed matplotlib in another part.
>>>>
>>>> No, but single buildouts are used to install different sections with
>>>> entirely different requirements, including different Python versions.
>>>
>>> This feels like needless complexity to me.
>>
>> This is a requirement we had here at ZC. ?It wasn't
>> needless.
>>
>>> If a different python is needed, it should be in its own buildout.
>>> If you need to bundle a bunch of buildouts together because of this, use
>>> a
>>> recipe that runs "sub buildouts" in a separate process...
>>
>> It's possible that this would be a better approach. ?It's true that
>> supporting multiple Python interpreters is a pain. ?I don't have this
>> need atm, so I'm not motivated to try your solution. :)
>>
>> I wonder what other people think. ?Does anyone else have current
>> need to deal with multiple Python versions in the same buildout?
>>
>> Jim
>
> I am developing vimpdb which I obviously want to be compatible with multiple
> python versions.
>
> I was planning to write ?a single buildout to build the various testrunners.

I encourage you to try it and see how it works for you, and report back.

I've done this in the past, but:

- It was awkward for other developers who didn't have the same versions of
  Python installed and who didn't generally have the mind set to try to
  actively develop against multiple versions simultaneously.

- The fact that the recipes all run in the buildout process, and thus
  with whatever version of buildout was used, led to odd errors. For
  example the zc.testrunner recipe had (maybe still has) trouble
  generating test scripts for target Python versions different than what
  it was run with. (It didn't always have this problem.)

Jim

-- 
Jim Fulton

From gotcha at bubblenet.be  Thu Sep  2 15:05:34 2010
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Thu, 02 Sep 2010 15:05:34 +0200
Subject: [Distutils] different python versions in one buildout?!
In-Reply-To: <AANLkTik9ZKxJdzRho_bCA_ikeTSpec671zaB2quCgL1N@mail.gmail.com>
References: <E025916A-57C9-437B-8C2C-4A0EA0AE4D16@canonical.com>
	<i50an3$96j$1@dough.gmane.org> <i50l08$ocb$1@dough.gmane.org>
	<C50784F5-855F-4FC4-878A-7CB9008A6591@canonical.com>
	<i52p1e$dur$1@dough.gmane.org>
	<19BF88C4-9AE3-46B0-BBCE-6115F4A4C625@canonical.com>
	<4C777604.6050509@vanrees.org>
	<94B2F054-FA29-430B-94B1-AAB2B04F748F@canonical.com>
	<4C7BE505.5020208@simplistix.co.uk>
	<AANLkTimx5Edv17G-nq-PXkasP4r0BE3BGJ4NZSNf-MV0@mail.gmail.com>
	<i5nusg$1hp$1@dough.gmane.org>
	<AANLkTik9ZKxJdzRho_bCA_ikeTSpec671zaB2quCgL1N@mail.gmail.com>
Message-ID: <4C7FA11E.6010603@bubblenet.be>

Le 02/09/10 14:53, Jim Fulton a ?crit :
> On Thu, Sep 2, 2010 at 6:39 AM, Godefroid Chapelle<gotcha at bubblenet.be>  wrote:
>>
>> I am developing vimpdb which I obviously want to be compatible with multiple
>> python versions.
>>
>> I was planning to write  a single buildout to build the various testrunners.
>
> I encourage you to try it and see how it works for you, and report back.

I will.

>
> I've done this in the past, but:
>
> - It was awkward for other developers who didn't have the same versions of
>    Python installed and who didn't generally have the mind set to try to
>    actively develop against multiple versions simultaneously.
>
> - The fact that the recipes all run in the buildout process, and thus
>    with whatever version of buildout was used, led to odd errors. For
>    example the zc.testrunner recipe had (maybe still has) trouble
>    generating test scripts for target Python versions different than what
>    it was run with. (It didn't always have this problem.)

Thanks for that information

>
> Jim

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

From crucialfelix at gmail.com  Thu Sep  2 16:48:21 2010
From: crucialfelix at gmail.com (felix)
Date: Thu, 2 Sep 2010 16:48:21 +0200
Subject: [Distutils] buildout removes parts on any change
Message-ID: <AANLkTin-WDW6hk21=fyE9+QopQ93u9t3dZTHCvb3aGmd@mail.gmail.com>

hello,

I'm quite fond of buildout, but a few things have taken me some months to
really figure out.

Buildout will remove any files installed by recipes when it senses that its
top parts or eggs section has changed.

I would love to avoid this as most of these removals are not needed, they
just get the same thing reinstalled afterwards,
lengthen the deploy time considerably and cause nasty surprises for the
server if its actually running.

Perhaps I'm not supposed to be using this for pushing changes to a live
server ?  I'm using django and if anything changed
on the top parts/eggs then it gets reinstalled

(even from the download-cache this takes quite a while and causes bad
burps on the server by removing templates)

I see that there is a buildout::uninstall entry point for recipes to run
extra code,  but no explicit uninstall method for the recipes.

Would it be possible to allow the recipe to implement uninstall if it
chooses to ?  My django deploy could then be made to be lightening quick.


-felix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100902/03b8465f/attachment.html>

From jim at zope.com  Thu Sep  2 17:48:31 2010
From: jim at zope.com (Jim Fulton)
Date: Thu, 2 Sep 2010 11:48:31 -0400
Subject: [Distutils] buildout removes parts on any change
In-Reply-To: <AANLkTin-WDW6hk21=fyE9+QopQ93u9t3dZTHCvb3aGmd@mail.gmail.com>
References: <AANLkTin-WDW6hk21=fyE9+QopQ93u9t3dZTHCvb3aGmd@mail.gmail.com>
Message-ID: <AANLkTik85JeH7A_tvEyOrDqmozQKjszB1z3Jf8V4gYj4@mail.gmail.com>

On Thu, Sep 2, 2010 at 10:48 AM, felix <crucialfelix at gmail.com> wrote:
>
> hello,
> I'm quite fond of buildout, but a few things have taken me some months to
> really figure out.
> Buildout will remove any files installed by recipes when it senses that its
> top parts or eggs section has changed.
> I would love to avoid this as most of these removals are not needed, they
> just get the same thing reinstalled afterwards,
> lengthen the deploy time considerably and cause nasty surprises for the
> server if its actually running.
> Perhaps I'm not supposed to be using this for pushing changes to a live
> server ? ?I'm using django and if anything changed
> on the top parts/eggs then it gets reinstalled
> (even from the download-cache this takes quite a while and causes bad
> burps?on the server by removing templates)
> I see that there is a buildout::uninstall entry point for recipes to run
> extra code, ?but no explicit uninstall method for the recipes.
> Would it be possible?to allow the recipe to implement uninstall if it
> chooses to ? ?My django deploy could then be made to be lightening quick.

It's not possible for a recipe to provide an uninstall method, but you
can provide an uninstall recipe, which I consider equivalent.  I'd be
open to allowing an uninstall method on a regular recipe, but this
wouldn't let you do anything you can't do now.

Buildout provides a default policy of removing installed files and
directories *reported by the install method*.  I think this is a
reasonable default policy.  It also allows a part to be uninstalled
even if the original recipe code is unavalable for some reason.

A recipe author can completely replace this default policy by:

- Not reporting any installed files in the install method of an
  install recipe, and by

- providing an uninstall recipe (entry point) that does whatever
  uninstall logic seems desireable.

As an aside, wrt production deployment:

- We use buildouts to build rpms used to deploy software. Deploying via a
  binary RPM (or a deb or whatever) is much faster than deploying via
  buildout, but there is still a small window in which files are replaced.
  This hasn't been a problem for us because our templates are held in
  memory (and reread from disk when changed).

- We use buildouts to install/update configuration files independent of
  software. Since the configuration files are written on process
  restarts, it's OK if they're missing for short periods of time.
  The recipes needed by this are installed as part of the software
  RPM, so there's no need to download anything and buildout is run in
  offline mode.

Jim

--
Jim Fulton

From crucialfelix at gmail.com  Thu Sep  2 18:50:07 2010
From: crucialfelix at gmail.com (felix)
Date: Thu, 2 Sep 2010 18:50:07 +0200
Subject: [Distutils] buildout removes parts on any change
In-Reply-To: <AANLkTik85JeH7A_tvEyOrDqmozQKjszB1z3Jf8V4gYj4@mail.gmail.com>
References: <AANLkTin-WDW6hk21=fyE9+QopQ93u9t3dZTHCvb3aGmd@mail.gmail.com>
	<AANLkTik85JeH7A_tvEyOrDqmozQKjszB1z3Jf8V4gYj4@mail.gmail.com>
Message-ID: <AANLkTi=A6K-vfk+x2X4wOZKEq_aES87yV+4GHT96C1H2@mail.gmail.com>

does this fairly represent the policy :  buildout removes all files
installed by parts anytime the top parts/develop/egg section changes because
"paranoid is safer".

I can imagine there would be problems, especially when parts depend on other
parts. (checking versions etc)


On Thu, Sep 2, 2010 at 5:48 PM, Jim Fulton <jim at zope.com> wrote:

>
> Buildout provides a default policy of removing installed files and
> directories *reported by the install method*.  I think this is a
> reasonable default policy.  It also allows a part to be uninstalled
> even if the original recipe code is unavalable for some reason.
>

Right, and I've run into that.  but actually at that time I had renamed a
develop egg and the buildout failed because the original was missing.

maybe it works for parts but not for develop ?

A recipe author can completely replace this default policy by:
>
> - Not reporting any installed files in the install method of an
>  install recipe, and by
>
> - providing an uninstall recipe (entry point) that does whatever
>  uninstall logic seems desireable.
>

this would work, but it would be a hack and would be a problem when it
really
does need to get uninstalled.

but I've got a brighter idea:  rather than shutil.copy the whole of django
in each time,
just do a symlink from the download cache.

safe and quick to remove and install




>
> As an aside, wrt production deployment:
>
> - We use buildouts to build rpms used to deploy software. Deploying via a
>  binary RPM (or a deb or whatever)


oooh...


- We use buildouts to install/update configuration files independent of
>  software.
>  The recipes needed by this are installed as part of the software
>  RPM,


nice, I get it now


does the second buildout get run by the RPM's post-install scripts ?

or do you just install it, then run the config-file buildouts ?

I don't know much about rpm


I've had blow ups when something went wrong using just buildout and then
there isn't a safe way to back out.
tried to add lxml the other day and it failed to build.

so this is definitely a solution for that.


-felix


>
> Jim
>
> --
> Jim Fulton
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100902/40270823/attachment.html>

From jim at zope.com  Thu Sep  2 22:23:21 2010
From: jim at zope.com (Jim Fulton)
Date: Thu, 2 Sep 2010 16:23:21 -0400
Subject: [Distutils] buildout removes parts on any change
In-Reply-To: <AANLkTi=A6K-vfk+x2X4wOZKEq_aES87yV+4GHT96C1H2@mail.gmail.com>
References: <AANLkTin-WDW6hk21=fyE9+QopQ93u9t3dZTHCvb3aGmd@mail.gmail.com>
	<AANLkTik85JeH7A_tvEyOrDqmozQKjszB1z3Jf8V4gYj4@mail.gmail.com>
	<AANLkTi=A6K-vfk+x2X4wOZKEq_aES87yV+4GHT96C1H2@mail.gmail.com>
Message-ID: <AANLkTi=jOog7D64xSKYyVsEafKg=usky9Oi5X6NS3c+4@mail.gmail.com>

On Thu, Sep 2, 2010 at 12:50 PM, felix <crucialfelix at gmail.com> wrote:
>
> does this fairly represent the policy : ?buildout removes all files
> installed by parts anytime the top parts/develop/egg section changes because
> "paranoid is safer".

Basically, a part is reinstalled (uninstalled and then installed) any time
the the recipe or any of its dependencies changes and any time
any of the data read by the recipe changes.  The default policy
doesn't remove all files installed by a part, only those reported by the part.
Some recipes intentionally don't report all of the paths they install.


> I can imagine there would be problems, especially when parts depend on other
> parts. (checking versions etc)

>From the buildout documentation (such as it is):

"When buildout is run, it saves configuration data for installed parts
in a file named ".installed.cfg". In subsequent runs, it compares
part-configuration data stored in the .installed.cfg file and the
part-configuration data loaded from the configuration files as
modified by recipe constructors to decide if the configuration of a
part has changed. If the configuration has changed, or if the recipe
has changed, then the part is uninstalled and reinstalled. The
buildout only looks at the part's options, so any data used to
configure the part needs to be reflected in the part's options. It is
the job of a recipe constructor to make sure that the options include
all relevant data."

You might find it interesting to look at .installed.cfg to get more
insights into exactly what information is used.


>
> On Thu, Sep 2, 2010 at 5:48 PM, Jim Fulton <jim at zope.com> wrote:
>>
>> Buildout provides a default policy of removing installed files and
>> directories *reported by the install method*. ?I think this is a
>> reasonable default policy. ?It also allows a part to be uninstalled
>> even if the original recipe code is unavalable for some reason.
>
> Right, and I've run into that. ?but actually at that time I had renamed a
> develop egg and the buildout failed because the original was missing.
> maybe it works for parts but not for develop ?
>>
>> A recipe author can completely replace this default policy by:
>>
>> - Not reporting any installed files in the install method of an
>> ?install recipe, and by
>>
>> - providing an uninstall recipe (entry point) that does whatever
>> ?uninstall logic seems desireable.
>
> this would work, but it would be a hack and would be a problem when it
> really
> does need to get uninstalled.

True.  I guess a better approach might be to supply a re-install
hook (either a new entry point or a installer method) that, if
present, would get called *instead* of uninstalling and
installing. I'm not sure that any recipe writers would want to work
that hard to solve this particular problem.

...

>> - We use buildouts to install/update configuration files independent of
>> ?software.
>> ?The recipes needed by this are installed as part of the software
>> ?RPM,
>
> nice, I get it now
>
> does the second buildout get run by the RPM's post-install scripts ?

No. The main idea is that configuration and software configuration are
separate activities.  It always annoys me when I install apache or a
relational database software and, as a result, there are servers
*running* on my system. I don't mind help getting things running, but
I'd much rather that be a separate step. I'd also like to have more
than one shot at getting things running.

>
> or do you just install it, then run the config-file buildouts ?

Yes.  We also have scripts that make this a bit easier based on our
deployment patterns.  These scripts look in standard places in the
file system for config files, and runs buildout with options that tell
it where to find recipes installed with an application and is prevented
from trying to download software.

> I don't know much?about rpm

The idea isn't really rpm (or even system packaging) specific.

>
> I've had blow ups when something went wrong using just buildout and then
> there isn't a safe way to back out.
> tried to add lxml the other day and it failed to build.
> so this is definitely a solution for that.

Doing the building ahead of time is a plus on multiple levels.
Using systems packaging tools also helps your relationship with your
sysadmins. :)

For the configuration part, it would be nice if buildout had better
tools to help you back out of problems or avoid them. For example, a
dry-run option that told you what would be changed by running buildout
would be nice.

Jim

-- 
Jim Fulton

From crucialfelix at gmail.com  Thu Sep  2 23:17:17 2010
From: crucialfelix at gmail.com (felix)
Date: Thu, 2 Sep 2010 23:17:17 +0200
Subject: [Distutils] buildout removes parts on any change
In-Reply-To: <AANLkTi=jOog7D64xSKYyVsEafKg=usky9Oi5X6NS3c+4@mail.gmail.com>
References: <AANLkTin-WDW6hk21=fyE9+QopQ93u9t3dZTHCvb3aGmd@mail.gmail.com>
	<AANLkTik85JeH7A_tvEyOrDqmozQKjszB1z3Jf8V4gYj4@mail.gmail.com>
	<AANLkTi=A6K-vfk+x2X4wOZKEq_aES87yV+4GHT96C1H2@mail.gmail.com>
	<AANLkTi=jOog7D64xSKYyVsEafKg=usky9Oi5X6NS3c+4@mail.gmail.com>
Message-ID: <AANLkTi=pa8GKWGB4Wq04zOM6rxsnQMT5eoaV_-Tg-wCw@mail.gmail.com>

> For the configuration part, it would be nice if buildout had better
> tools to help you back out of problems or avoid them. For example, a
> dry-run option that told you what would be changed by running buildout
> would be nice.
>

how about building just one part (or even building it to a tmp directory and
moving on success)

eg. lxml
I didn't know this would fail, it worked on OS X

./bin/buildout -c live.cfg -build-egg lxml
./bin/buildout -c live.cfg -build-part libevent

this would fetch and build just that egg/part and we could watch it fail or
succeed
before proceeding and doing the whole buildout that is supposed to use this
new egg.

also then an actual deploy wouldn't have to wait for compiling etc. which
shouldn't happen
during a live-server deploy

caveat: its not harmless if its a rebuild of something in use or the egg
will kick another egg out of the nest
also: if the part triggers other existing dependencies then they will get
built.

dry run to a different buildout directory also sounds good, and probably not
to tricky to do.



thanks very much for your time jim !  and for buildout, I've been using it
for about 6 months
and the server configs are much more sane now.

django-celery-rabbitmq-memcached-nginx-apache-supervisor
many many eggs,
plus scripts for server checking, cron jobs
etc.

its unmanageable without buildout





> Jim
>
> --
> Jim Fulton
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100902/cdf33d24/attachment.html>

From nickle at gmail.com  Fri Sep  3 11:03:05 2010
From: nickle at gmail.com (Nick Leaton)
Date: Fri, 3 Sep 2010 10:03:05 +0100
Subject: [Distutils] --prefix
Message-ID: <AANLkTi=8ivfoJ2aF9u6CORZ3X8bsUXDeKQKf-5uJ6UVX@mail.gmail.com>

How can I get access to the value of --prefix from code during an install?

Thanks

-- 
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100903/8ea93038/attachment-0001.html>

From skip at pobox.com  Fri Sep  3 12:04:55 2010
From: skip at pobox.com (skip at pobox.com)
Date: Fri, 3 Sep 2010 05:04:55 -0500
Subject: [Distutils] --prefix
In-Reply-To: <AANLkTi=8ivfoJ2aF9u6CORZ3X8bsUXDeKQKf-5uJ6UVX@mail.gmail.com>
References: <AANLkTi=8ivfoJ2aF9u6CORZ3X8bsUXDeKQKf-5uJ6UVX@mail.gmail.com>
Message-ID: <19584.51271.45017.978168@montanaro.dyndns.org>


    Nick> How can I get access to the value of --prefix from code during an
    Nick> install?

sys.prefix I believe.

-- 
Skip Montanaro - skip at pobox.com - http://www.smontanaro.net/

From merwok at netwok.org  Fri Sep  3 17:24:56 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 03 Sep 2010 17:24:56 +0200
Subject: [Distutils] --prefix
In-Reply-To: <AANLkTi=8ivfoJ2aF9u6CORZ3X8bsUXDeKQKf-5uJ6UVX@mail.gmail.com>
References: <AANLkTi=8ivfoJ2aF9u6CORZ3X8bsUXDeKQKf-5uJ6UVX@mail.gmail.com>
Message-ID: <4C811348.6090305@netwok.org>

> How can I get access to the value of --prefix from code during an install?

I assume you mean the --prefix option of the install command. What kind
of code needs to access this value? Is it a distutils command?

Regards


From pje at telecommunity.com  Fri Sep  3 17:38:51 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 03 Sep 2010 11:38:51 -0400
Subject: [Distutils] --prefix
In-Reply-To: <AANLkTi=8ivfoJ2aF9u6CORZ3X8bsUXDeKQKf-5uJ6UVX@mail.gmail.c
 om>
References: <AANLkTi=8ivfoJ2aF9u6CORZ3X8bsUXDeKQKf-5uJ6UVX@mail.gmail.com>
Message-ID: <20100903153902.D7F0C3A40A5@sparrow.telecommunity.com>

At 10:03 AM 9/3/2010 +0100, Nick Leaton wrote:
>How can I get access to the value of --prefix from code during an install?

If you mean from setup.py, you can't.  You would need to subclass one 
of the distutils commands and ue the cmdclass argument to 
setup().  (sys.prefix is the wrong answer, by the way; it contains 
the prefix where python was installed, *not* the prefix being installed to!)

Even then, you don't want the value of --prefix, because that doesn't 
necessarily tell you where something should be installed!  Distutils 
has multiple installation schemes, many of which don't use --prefix 
at all.  --prefix is used to calculate various paths, but those paths 
can be specified individually, without using a --prefix.

What's more, when a --root installation is taking place, putting 
things under --prefix would break bdist_rpm, bdist_wininst, 
bdist_msi, and other bdist_* commands, which are actually installing 
files to a temporary location in order to build an installation 
package, rather than "really" installing anything.

In short, you're asking the wrong question, but if you can let us 
know what it is you're planning to *do* with this information, there 
may be an easier way to go about whatever you're actually trying to accomplish.


From nickle at gmail.com  Fri Sep  3 17:46:32 2010
From: nickle at gmail.com (Nick Leaton)
Date: Fri, 3 Sep 2010 16:46:32 +0100
Subject: [Distutils] --prefix
In-Reply-To: <20100903153902.D7F0C3A40A5@sparrow.telecommunity.com>
References: <AANLkTi=8ivfoJ2aF9u6CORZ3X8bsUXDeKQKf-5uJ6UVX@mail.gmail.com>
	<20100903153902.D7F0C3A40A5@sparrow.telecommunity.com>
Message-ID: <AANLkTi=M50DwyN2UEvtL066s6b020O-_7HrMifgMhA5O@mail.gmail.com>

I had an inkling I might be asking the wrong question.

It relates to releasing an app that has the following features.

1) Internal package
2) A couple of scripts
3) A dependency on an external package/library (Already packaged in its own
right).
4) A couple of dll or equivalent on Unix.

We don't want to install into site-packages, we want to keep that clean. We
would like to install all the above into one directory structure, and set a
python path to poin to the appropriate directory. Almost xcopy installation
if that makes sense.

I can see two ways of doing this.

1. In a temporary build area build up everything and then package it
2. In the install script, as a post_install action install the external
package and the dlls

I'm trying to do the second, and as you say its the prefix for where python
is installed. I could parse the command line, but that smells it has to be
wrong.

Advice please?

Nick


On 3 September 2010 16:38, P.J. Eby <pje at telecommunity.com> wrote:

> At 10:03 AM 9/3/2010 +0100, Nick Leaton wrote:
>
>> How can I get access to the value of --prefix from code during an install?
>>
>
> If you mean from setup.py, you can't.  You would need to subclass one of
> the distutils commands and ue the cmdclass argument to setup().  (sys.prefix
> is the wrong answer, by the way; it contains the prefix where python was
> installed, *not* the prefix being installed to!)
>
> Even then, you don't want the value of --prefix, because that doesn't
> necessarily tell you where something should be installed!  Distutils has
> multiple installation schemes, many of which don't use --prefix at all.
>  --prefix is used to calculate various paths, but those paths can be
> specified individually, without using a --prefix.
>
> What's more, when a --root installation is taking place, putting things
> under --prefix would break bdist_rpm, bdist_wininst, bdist_msi, and other
> bdist_* commands, which are actually installing files to a temporary
> location in order to build an installation package, rather than "really"
> installing anything.
>
> In short, you're asking the wrong question, but if you can let us know what
> it is you're planning to *do* with this information, there may be an easier
> way to go about whatever you're actually trying to accomplish.
>
>


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

From pje at telecommunity.com  Fri Sep  3 18:09:37 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 03 Sep 2010 12:09:37 -0400
Subject: [Distutils] Need for ability to limit dependencies similar to
 'extras'
In-Reply-To: <12C7AB425F0DD546B6049311F827C74E0974FDA4A1@VA3DIAXVS141.RE
	D001.local>
References: <12C7AB425F0DD546B6049311F827C74E0974FDA4A1@VA3DIAXVS141.RED001.local>
Message-ID: <20100903160947.F2FD73A40A5@sparrow.telecommunity.com>

At 04:53 AM 9/1/2010 -0700, Jason R. Coombs wrote:
>We're using setuptools for packaging our Python projects. Several of our
>projects have a server/client aspect to them, where the server is a
>full-fledged service with a lot of dependencies and the client is just an API
>for accessing the server, probably with just a few dependencies.  We want a
>way to install the package with or without these dependencies. With the
>current implementation of setuptools, I believe we have two choices.
>
>1) Refactor the package into three packages: project_server, project_client,
>and project_common. Project_server would then contain the additional
>dependencies.
>2) Use the extras_require for the server facet of the project. So
>"easy_install project" installs the common dependencies and "easy_install
>project[server]" installs the additional dependencies.
>
>The second option is what we're using, but the [server] facet is the most
>common usage. We would prefer instead to have a way to "easy_install
>project[client]" which would _limit_ the dependencies needed, and
>"easy_install project" would install the full set of dependencies.
>
>Has anyone heard of a plugin which does this? Is it even possible that a
>plugin could trim out dependencies?

No, and no.  A feature like this would have to be added to 
setuptools, and even then, existing setuptools installations would 
not know how to actually use the feature.  In other words, even if 
this were added, you would have the problem that, even many years 
from now, there would still be users whose setuptools installation 
wouldn't understand how to handle your special setup.

The most practical solution is to either go to option #1, or continue 
to require explicitly specifying [client], [server] or [client,server]


From pje at telecommunity.com  Fri Sep  3 18:29:14 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 03 Sep 2010 12:29:14 -0400
Subject: [Distutils] --prefix
In-Reply-To: <AANLkTi=M50DwyN2UEvtL066s6b020O-_7HrMifgMhA5O@mail.gmail.c
 om>
References: <AANLkTi=8ivfoJ2aF9u6CORZ3X8bsUXDeKQKf-5uJ6UVX@mail.gmail.com>
	<20100903153902.D7F0C3A40A5@sparrow.telecommunity.com>
	<AANLkTi=M50DwyN2UEvtL066s6b020O-_7HrMifgMhA5O@mail.gmail.com>
Message-ID: <20100903162924.5D9D73A40A5@sparrow.telecommunity.com>

At 04:46 PM 9/3/2010 +0100, Nick Leaton wrote:
>I had an inkling I might be asking the wrong question.
>
>It relates to releasing an app that has the following features.
>
>1) Internal package
>2) A couple of scripts
>3) A dependency on an external package/library (Already packaged in 
>its own right).
>4) A couple of dll or equivalent on Unix.

Note that dependencies can be automatically installed if you use 
setuptools in your setup.py.  The rest would also be part of a normal 
setup script.


>We don't want to install into site-packages, we want to keep that clean.

Why don't you leave that up to the person installing your 
package?  Is this for a small targeted audience or for general release?

If it's for general release to people using Python, you should most 
definitely let them decide where to install it, or you're going to 
make a lot of people really annoyed with you.  ;-)

However, if it's to a targeted audience of non-Python users, why not 
just have your installer pass appropriate installation locations to 
setup.py install, to explicitly set things up the way you want them?

Either way, it doesn't seem like doing anything special in your 
setup.py is a good idea.  (Apart from maybe using setuptools so you 
can specify dependencies.)


>  We would like to install all the above into one directory 
> structure, and set a python path to poin to the appropriate directory.

Why?

I ask these questions because there's more than one way to 
(potentially) accomplish this, but so far it doesn't sound like 
there's any reason for you to change the way distutils does things by 
default, and leave it up to the person doing the installation to 
decide where they want to put things, perhaps with some docs 
recommending a particular location.


From setuptools at bugs.python.org  Sun Sep  5 16:44:38 2010
From: setuptools at bugs.python.org (Stefano Rivera)
Date: Sun, 05 Sep 2010 14:44:38 +0000
Subject: [Distutils] [issue114] Add option to suppress 2to3 fixes
In-Reply-To: <1283697878.21.0.12134384964.issue114@psf.upfronthosting.co.za>
Message-ID: <1283697878.21.0.12134384964.issue114@psf.upfronthosting.co.za>


New submission from Stefano Rivera <python-setuptools at rivera.za.net>:

It would be handy if specific 2to3 fixers could be disabled during 2to3. Here's a patch to do it. The equivalent patch for distutils2 would be much bigger, so I'm proposing it here for discussion, first.

----------
files: skip-fixers.patch
messages: 541
nosy: stefanor
priority: feature
status: unread
title: Add option to suppress 2to3 fixes
Added file: http://bugs.python.org/setuptools/file70/skip-fixers.patch

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue114>
_______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skip-fixers.patch
Type: text/x-patch
Size: 1527 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100905/c5ac8960/attachment.bin>

From sayrich1 at gmail.com  Fri Sep  3 23:19:18 2010
From: sayrich1 at gmail.com (Phil Sayre & Jean Richon)
Date: Fri, 3 Sep 2010 14:19:18 -0700
Subject: [Distutils] Need for some guidance
Message-ID: <AANLkTikvXPUurWxLgQCjujAkAj2CXWzCHrb6BCuJae02@mail.gmail.com>

Hello,
     My name is Phil Sayre.  My email is sayrich1 at gmail.com.  I have written
a Python program which I will be using in my capacity as treasurer for a
small, 200 member group of chamber music aficionados.  This program provides
an interactive interface to the person sitting in front of a laptop
computer, allowing him to look up a member's information, given the member's
name, and determine whether or not he has paid his dues for the current
year.  It allows for corrections to the data, e.g., address, email, phone.
When the member pays $10, I will be able to mark him paid on the current
date with a mouse click.  This program is easy to use and much faster and
simpler than using an Excel spreadsheet, which is the system I have had to
deal with for the past 2 years.

That is the justification for the program.  Now I am wondering if I might
not be able to offer this program to other similar organizations, for
possibly a modest price.  To do this I would have to know something about
packaging it as an installable product.  I think the proper place to look
for answers is the Distutils sig, isn't it?  But I confess at this
point, the documentation is just extremely confusing.

My program uses the CSV module to read and write 'comma separated
value' records from/to an Excel produced file, a package called EasyGui
which provides the user interface, and the modules shelve, sys, string,
cPickle, datetime.  Shelve is the method which affords the fast record
lookup in the data base.   The csv module is distributed with Python.

I am planning, for the time being, to offer this to only Windows users.

When I downloaded Python, I selected Pythonwin for my own laptop running
Windows XP.  I don't really know much about this package other than it runs
under Windows.

For my probable customers, I don't expect that any of them will have a
Python system installed.  And I don't need to provide them with a means of
editing and compiling Python programs--but I clearly will need to provide
the Python execution engine.  But perhaps this is not separable from the
compiler--I don't know.

Where do fit within the Distutil spectrum?  I think it's section 5, but I
can't get beyond the first paragraph.

I'd appreciate any help that is available.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100903/68322870/attachment.html>

From fuzzyman at voidspace.org.uk  Mon Sep  6 17:44:28 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 6 Sep 2010 16:44:28 +0100
Subject: [Distutils] Need for some guidance
In-Reply-To: <AANLkTikvXPUurWxLgQCjujAkAj2CXWzCHrb6BCuJae02@mail.gmail.com>
References: <AANLkTikvXPUurWxLgQCjujAkAj2CXWzCHrb6BCuJae02@mail.gmail.com>
Message-ID: <AANLkTi=uEWimr3PVmOYrE8Ve5WXmfDohnjFc0LoVKn0q@mail.gmail.com>

On 3 September 2010 22:19, Phil Sayre & Jean Richon <sayrich1 at gmail.com>wrote:

> Hello,
>      My name is Phil Sayre.  My email is sayrich1 at gmail.com.  I have
> written a Python program which I will be using in my capacity as treasurer
> for a small, 200 member group of chamber music aficionados.  This program
> provides an interactive interface to the person sitting in front of a laptop
> computer, allowing him to look up a member's information, given the member's
> name, and determine whether or not he has paid his dues for the current
> year.  It allows for corrections to the data, e.g., address, email, phone.
> When the member pays $10, I will be able to mark him paid on the current
> date with a mouse click.  This program is easy to use and much faster and
> simpler than using an Excel spreadsheet, which is the system I have had to
> deal with for the past 2 years.
>
> That is the justification for the program.  Now I am wondering if I might
> not be able to offer this program to other similar organizations, for
> possibly a modest price.  To do this I would have to know something about
> packaging it as an installable product.  I think the proper place to look
> for answers is the Distutils sig, isn't it?  But I confess at this
> point, the documentation is just extremely confusing.
>


You may be better off using something like py2exe (along with an installer
creator like Wix) to bundle your application as a standalone application.
You will still need to know a bit about distutils but you will be better off
following the py2exe user guide and asking questions on the py2exe list
(unless they redirect you back here for anything):

    http://www.py2exe.org/

All the best,

Michael Foord



> My program uses the CSV module to read and write 'comma separated
> value' records from/to an Excel produced file, a package called EasyGui
> which provides the user interface, and the modules shelve, sys, string,
> cPickle, datetime.  Shelve is the method which affords the fast record
> lookup in the data base.   The csv module is distributed with Python.
>
> I am planning, for the time being, to offer this to only Windows users.
>
> When I downloaded Python, I selected Pythonwin for my own laptop running
> Windows XP.  I don't really know much about this package other than it runs
> under Windows.
>
> For my probable customers, I don't expect that any of them will have a
> Python system installed.  And I don't need to provide them with a means of
> editing and compiling Python programs--but I clearly will need to provide
> the Python execution engine.  But perhaps this is not separable from the
> compiler--I don't know.
>
> Where do fit within the Distutil spectrum?  I think it's section 5, but I
> can't get beyond the first paragraph.
>
> I'd appreciate any help that is available.
>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>


-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100906/29679bae/attachment.html>

From merwok at netwok.org  Mon Sep  6 20:36:34 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 06 Sep 2010 20:36:34 +0200
Subject: [Distutils] Need for some guidance
In-Reply-To: <AANLkTikvXPUurWxLgQCjujAkAj2CXWzCHrb6BCuJae02@mail.gmail.com>
References: <AANLkTikvXPUurWxLgQCjujAkAj2CXWzCHrb6BCuJae02@mail.gmail.com>
Message-ID: <4C8534B2.8070002@netwok.org>

Hello

> That is the justification for the program.  Now I am wondering if I might
> not be able to offer this program to other similar organizations, for
> possibly a modest price.  To do this I would have to know something about
> packaging it as an installable product.  I think the proper place to look
> for answers is the Distutils sig, isn't it?  But I confess at this
> point, the documentation is just extremely confusing.
> [...]
> Where do fit within the Distutil spectrum?  I think it's section 5, but I
> can't get beyond the first paragraph.

Could you tell us what especially is confusing, and what sort of
document you would have liked to find? We want to improve the
documentation for distutils2, the next gen.

Thanks.


From doug.hellmann at gmail.com  Wed Sep  8 13:34:41 2010
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Wed, 8 Sep 2010 07:34:41 -0400
Subject: [Distutils] problem with sdist for nested packages
Message-ID: <29EAA4F4-F241-4A29-A3F4-08FEFDD406C3@gmail.com>

I'm having some problems creating an sdist for a nested package where some of the levels only include __init__.py and the subdirectories.  The full list of files is fairly long, but here's a snippet to give you an idea of the layout for the inputs:

PyMOTW/xml
PyMOTW/xml/__init__.py
PyMOTW/xml/etree
PyMOTW/xml/etree/__init__.py
PyMOTW/xml/etree/ElementTree
PyMOTW/xml/etree/ElementTree/__init__.py
PyMOTW/xml/etree/ElementTree/ElementTree_create.py
PyMOTW/xml/etree/ElementTree/...

When I build the sdist, I get:

build/lib/PyMOTW/xml
build/lib/PyMOTW/xml/etree
build/lib/PyMOTW/xml/etree/ElementTree
build/lib/PyMOTW/xml/etree/ElementTree/__init__.py
build/lib/PyMOTW/xml/etree/ElementTree/ElementTree_create.py
build/lib/PyMOTW/xml/etree/ElementTree/...

The __init__.py at the "xml" and "xml/etree" levels are not included.  As a result, the sdist won't install because it wants to populate a PyMOTW.ElementTree package but the directory doesn't exist.  I also tried adding other .py files at those levels in the directory structure (in case an "empty" directory was being ignored), but that had no effect.

The traceback I get trying to install the sdist is:

Traceback (most recent call last):
  File "setup.py", line 7, in <module>
    paver.tasks.main()
  File "paver-minilib.zip/paver/tasks.py", line 621, in main
  File "paver-minilib.zip/paver/tasks.py", line 604, in _launch_pavement
  File "paver-minilib.zip/paver/tasks.py", line 569, in _process_commands
  File "paver-minilib.zip/paver/setuputils.py", line 146, in __call__
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/Users/dhellmann/.virtualenvs/pymotwtest/lib/python2.7/site-packages/distribute-0.6.10-py2.7.egg/setuptools/command/install.py", line 71, in run
    _install.run(self)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/install.py", line 563, in run
    self.run_command('build')
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build.py", line 127, in run
    self.run_command(cmd_name)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/Users/dhellmann/.virtualenvs/pymotwtest/lib/python2.7/site-packages/distribute-0.6.10-py2.7.egg/setuptools/command/build_py.py", line 77, in run
    self.build_packages()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build_py.py", line 366, in build_packages
    modules = self.find_package_modules(package, package_dir)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build_py.py", line 218, in find_package_modules
    self.check_package(package, package_dir)
  File "/Users/dhellmann/.virtualenvs/pymotwtest/lib/python2.7/site-packages/distribute-0.6.10-py2.7.egg/setuptools/command/build_py.py", line 192, in check_package
    init_py = _build_py.check_package(self, package, package_dir)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build_py.py", line 191, in check_package
    "package directory '%s' does not exist" % package_dir)
distutils.errors.DistutilsFileError: package directory 'PyMOTW/ElementTree' does not exist

Has anyone seen this problem before?

Thanks,
Doug


From doug.hellmann at gmail.com  Wed Sep  8 13:36:19 2010
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Wed, 8 Sep 2010 07:36:19 -0400
Subject: [Distutils] problem with sdist for nested packages
In-Reply-To: <29EAA4F4-F241-4A29-A3F4-08FEFDD406C3@gmail.com>
References: <29EAA4F4-F241-4A29-A3F4-08FEFDD406C3@gmail.com>
Message-ID: <32B51A44-F962-44D9-BF79-F01FEF233F87@gmail.com>

Forgot to include version info:

Python 2.7
distribute 0.6.10
Paver 1.0.3

Doug

On Sep 8, 2010, at 7:34 AM, Doug Hellmann wrote:

> I'm having some problems creating an sdist for a nested package where some of the levels only include __init__.py and the subdirectories.  The full list of files is fairly long, but here's a snippet to give you an idea of the layout for the inputs:
> 
> PyMOTW/xml
> PyMOTW/xml/__init__.py
> PyMOTW/xml/etree
> PyMOTW/xml/etree/__init__.py
> PyMOTW/xml/etree/ElementTree
> PyMOTW/xml/etree/ElementTree/__init__.py
> PyMOTW/xml/etree/ElementTree/ElementTree_create.py
> PyMOTW/xml/etree/ElementTree/...
> 
> When I build the sdist, I get:
> 
> build/lib/PyMOTW/xml
> build/lib/PyMOTW/xml/etree
> build/lib/PyMOTW/xml/etree/ElementTree
> build/lib/PyMOTW/xml/etree/ElementTree/__init__.py
> build/lib/PyMOTW/xml/etree/ElementTree/ElementTree_create.py
> build/lib/PyMOTW/xml/etree/ElementTree/...
> 
> The __init__.py at the "xml" and "xml/etree" levels are not included.  As a result, the sdist won't install because it wants to populate a PyMOTW.ElementTree package but the directory doesn't exist.  I also tried adding other .py files at those levels in the directory structure (in case an "empty" directory was being ignored), but that had no effect.
> 
> The traceback I get trying to install the sdist is:
> 
> Traceback (most recent call last):
>  File "setup.py", line 7, in <module>
>    paver.tasks.main()
>  File "paver-minilib.zip/paver/tasks.py", line 621, in main
>  File "paver-minilib.zip/paver/tasks.py", line 604, in _launch_pavement
>  File "paver-minilib.zip/paver/tasks.py", line 569, in _process_commands
>  File "paver-minilib.zip/paver/setuputils.py", line 146, in __call__
>  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command
>    cmd_obj.run()
>  File "/Users/dhellmann/.virtualenvs/pymotwtest/lib/python2.7/site-packages/distribute-0.6.10-py2.7.egg/setuptools/command/install.py", line 71, in run
>    _install.run(self)
>  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/install.py", line 563, in run
>    self.run_command('build')
>  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/cmd.py", line 326, in run_command
>    self.distribution.run_command(command)
>  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command
>    cmd_obj.run()
>  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build.py", line 127, in run
>    self.run_command(cmd_name)
>  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/cmd.py", line 326, in run_command
>    self.distribution.run_command(command)
>  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command
>    cmd_obj.run()
>  File "/Users/dhellmann/.virtualenvs/pymotwtest/lib/python2.7/site-packages/distribute-0.6.10-py2.7.egg/setuptools/command/build_py.py", line 77, in run
>    self.build_packages()
>  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build_py.py", line 366, in build_packages
>    modules = self.find_package_modules(package, package_dir)
>  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build_py.py", line 218, in find_package_modules
>    self.check_package(package, package_dir)
>  File "/Users/dhellmann/.virtualenvs/pymotwtest/lib/python2.7/site-packages/distribute-0.6.10-py2.7.egg/setuptools/command/build_py.py", line 192, in check_package
>    init_py = _build_py.check_package(self, package, package_dir)
>  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build_py.py", line 191, in check_package
>    "package directory '%s' does not exist" % package_dir)
> distutils.errors.DistutilsFileError: package directory 'PyMOTW/ElementTree' does not exist
> 
> Has anyone seen this problem before?
> 
> Thanks,
> Doug
> 


From eric at trueblade.com  Wed Sep  8 13:37:40 2010
From: eric at trueblade.com (Eric Smith)
Date: Wed, 08 Sep 2010 07:37:40 -0400
Subject: [Distutils] problem with sdist for nested packages
In-Reply-To: <29EAA4F4-F241-4A29-A3F4-08FEFDD406C3@gmail.com>
References: <29EAA4F4-F241-4A29-A3F4-08FEFDD406C3@gmail.com>
Message-ID: <4C877584.3050109@trueblade.com>

On 9/8/10 7:34 AM, Doug Hellmann wrote:
> I'm having some problems creating an sdist for a nested package where some of the levels only include __init__.py and the subdirectories.  The full list of files is fairly long, but here's a snippet to give you an idea of the layout for the inputs:

<snip>

> Has anyone seen this problem before?

What does your setup.py look like?

-- 
Eric.

From doug.hellmann at gmail.com  Wed Sep  8 18:00:06 2010
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Wed, 8 Sep 2010 12:00:06 -0400
Subject: [Distutils] problem with sdist for nested packages
In-Reply-To: <4C877584.3050109@trueblade.com>
References: <29EAA4F4-F241-4A29-A3F4-08FEFDD406C3@gmail.com>
	<4C877584.3050109@trueblade.com>
Message-ID: <A1B4B710-343C-486C-A454-B62BA5738F75@gmail.com>


On Sep 8, 2010, at 7:37 AM, Eric Smith wrote:

> On 9/8/10 7:34 AM, Doug Hellmann wrote:
>> I'm having some problems creating an sdist for a nested package where some of the levels only include __init__.py and the subdirectories.  The full list of files is fairly long, but here's a snippet to give you an idea of the layout for the inputs:
> 
> <snip>
> 
>> Has anyone seen this problem before?
> 
> What does your setup.py look like?

I'm using Paver, which wraps setuptools.  My pavement.py file is pasted below.  

Instead of explicitly listing packages, I use find_package_data() and then get the package names from that result.  The odd thing is I get a package "PyMOTW.ElementTree" but not "PyMOTW.xml.etree.ElementTree".  Maybe I'm misunderstanding/misusing find_package_data(), since that nested package is the only one I'm having problems with.  It seems to work fine for all of the other subdirectories of PyMOTW, but this is the only one where the real code is more than one level deep.

Doug



#!/usr/bin/env python
# encoding: utf-8
#
# Copyright (c) 2008 Doug Hellmann All rights reserved.
#
"""
"""

# Standard library
import os
import sys
import tabnanny
import traceback
import types

# Set up Paver
import paver
import paver.doctools
import paver.misctasks
from paver.path import path
from paver.easy import *
import paver.setuputils
paver.setuputils.install_distutils_tasks()
try:
    from sphinxcontrib import paverutils
except:
    paverutils = None

# TODO
# - move these variables to options?

# What project are we building?
PROJECT = 'PyMOTW'

# What version is this?
VERSION = '1.124'

# The sphinx templates expect the VERSION in the shell environment
os.environ['VERSION'] = VERSION

# What is the current module being documented?
MODULE = path('module').text().rstrip()
os.environ['MODULE'] = MODULE

# Read the long description to give to setup
README = path('README.txt').text()

# Scan the input for package information
# to grab any data files (text, images, etc.) 
# associated with sub-packages.
PACKAGE_DATA = paver.setuputils.find_package_data(PROJECT, 
                                                  package=PROJECT,
                                                  only_in_packages=True,
                                                  )

options(
    setup=Bunch(
        name = PROJECT,
        version = VERSION,
        
        description = 'Python Module of the Week Examples: ' + MODULE,
        long_description = README,

        author = 'Doug Hellmann',
        author_email = 'doug.hellmann at gmail.com',

        url = 'http://www.doughellmann.com/PyMOTW/',
        download_url = 'http://www.doughellmann.com/downloads/%s-%s.tar.gz' % \
                        (PROJECT, VERSION),

        classifiers = [ 'Development Status :: 5 - Production/Stable',
                        'Environment :: Console',
                        'Intended Audience :: Developers',
                        'Intended Audience :: Education',
                        'License :: OSI Approved :: BSD License',
                        'Operating System :: POSIX',
                        'Programming Language :: Python',
                        'Topic :: Software Development',
                        ],

        platforms = ('Any',),
        keywords = ('python', 'PyMOTW', 'documentation'),

        # It seems wrong to have to list recursive packages explicitly.
        packages = sorted(PACKAGE_DATA.keys()),
        package_data=PACKAGE_DATA,
        zip_safe=False,
        
        scripts=['motw'],

        ),
    
    sdist = Bunch(
    ),
    
    sdistext = Bunch(
        outdir='~/Desktop',
    ),
    
    sphinx = Bunch(
        sourcedir=PROJECT,
        docroot = '.',
        builder = 'html',
        doctrees='sphinx/doctrees',
        confdir = 'sphinx',
        template_args = { 'module':MODULE }
    ),

    html = Bunch(
        builddir='%s/docs' % PROJECT,
        outdir='%s/docs' % PROJECT,
        templates='pkg',
    ),

    text = Bunch(
        builddir='%s/docs' % PROJECT,
        outdir='%s/docs' % PROJECT,
        templates='pkg',
        builder='text',
    ),

    website=Bunch(
        templates = 'web',
        builddir = 'web',
        
        # What server hosts the website?
        server = 'www.doughellmann.com',
        server_path = '/var/www/doughellmann/DocumentRoot/PyMOTW/',

        # What template should be used for the web site HTML?
        template_source = '~/Devel/doughellmann/doughellmann/templates/base.html',
        template_dest = 'sphinx/templates/web/base.html',        
    ),
    
    sitemap_gen=Bunch(
        # Where is the config file for sitemap_gen.py?
        config='sitemap_gen_config.xml',
    ),
    
    pdf=Bunch(
        templates='pkg',
        builddir='web',
        builder='latex',
    ),
    
    blog=Bunch(
        sourcedir=path(PROJECT)/MODULE,
        builddir='blog_posts',
        outdir='blog_posts',
        confdir='sphinx/blog',
        doctrees='blog_posts/doctrees',
        in_file='index.html',
        out_file='blog.html',
        no_edit=False,
    ),
    
    # Some of the files include [[[ as part of a nested list data structure,
    # so change the tags cog looks for to something less likely to appear.
    cog=Bunch(
        beginspec='{{{cog',
        endspec='}}}',
        endoutput='{{{end}}}',
        includedir='PyMOTW',
    ),

    # Tell Paver to include extra parts that we use
    # but it doesn't ship in the minilib by default.
    minilib = Bunch(
        extra_files=['doctools'],
    ),

)

# Stuff commonly used symbols into the builtins so we don't have to
# import them in all of the cog blocks where we want to use them.
__builtins__['path'] = path

# Modified from paver.doctools._runcog
from paver.doctools import Includer, _cogsh
def _runcog(options, files, uncog=False):
    """Common function for the cog and runcog tasks."""
    
    from paver.cog import Cog
    options.order('cog', 'sphinx', add_rest=True)
    c = Cog()
    if uncog:
        c.options.bNoGenerate = True
    c.options.bReplace = True
    c.options.bDeleteCode = options.get("delete_code", False)
    includedir = options.get('includedir', None)
    if includedir:
        include = Includer(includedir, cog=c, 
                           include_markers=options.get("include_markers"))
        # load cog's namespace with our convenience functions.
        c.options.defines['include'] = include
        c.options.defines['sh'] = _cogsh(c)
    
    c.sBeginSpec = options.get('beginspec', '[[[cog')
    c.sEndSpec = options.get('endspec', ']]]')
    c.sEndOutput = options.get('endoutput', '[[[end]]]')
    
    basedir = options.get('basedir', None)
    if basedir is None:
        basedir = path(options.get('docroot', "docs")) / options.get('sourcedir', "")
    basedir = path(basedir)
        
    if not files:
        pattern = options.get("pattern", "*.rst")
        if pattern:
            files = basedir.walkfiles(pattern)
        else:
            files = basedir.walkfiles()
    for f in files:
        dry("cog %s" % f, c.processOneFile, f)
#

@task
@consume_args
def cog(options):
    """Run cog against all or a subset of the input source files.
    
    Examples::
    
      $ paver cog PyMOTW/atexit
      $ paver cog PyMOTW/atexit/index.rst
      $ paver cog
    
    See help on paver.doctools.cog for details on the standard
    options.
    """
    options.order('cog', 'sphinx', add_rest=True)
    # Figure out if we were given a filename or
    # directory, and scan the directory for files
    # if we need to.
    files_to_cog = getattr(options, 'args', [])
    if files_to_cog and os.path.isdir(files_to_cog[0]):
        dir_to_scan = path(files_to_cog[0])
        files_to_cog = dir_to_scan.walkfiles(options.get("pattern", "*.rst"))
    _runcog(options, files_to_cog)
    return

def remake_directories(*dirnames):
    """Remove the directories and recreate them.
    """
    for d in dirnames:
        d = path(d)
        if d.exists():
            d.rmtree()
        d.mkdir()
    return

@task
def html(options):
    "Generate HTML files."
    set_templates(options.html.templates)
    if paverutils is None:
        raise RuntimeError('Could not find sphinxcontrib.paverutils, will not be able to build HTML output.')
    paverutils.html(options)
    return

@task
@consume_args
def tabcheck(options):
    """Run tabnanny against the current module.
    """
    args = getattr(options, 'args', [])
    if not args:
        args = path('PyMOTW').glob('*')
    tabnanny.verbose = 1
    for module in args:
        tabnanny.check(module)
    return

@task
@consume_args
def update(options):
    """Run cog against the named module, then re-build the HTML.
    
    Examples::
    
      $ paver update atexit
    """
    options.order('update', 'sphinx', add_rest=True)
    args = getattr(options, 'args', [])
    if args:
        module = args[0]
    else:
        module = MODULE
    module_dir = 'PyMOTW/' + module
    tabnanny.check(module_dir)
    options.order('cog', 'sphinx', add_rest=True)
    options.args = [module_dir]
    cog(options)
    html(options)
    return
    

@task
def text(options):
    "Generate text files from rst input."
    if paverutils is None:
        raise RuntimeError('Could not find sphinxcontrib.paverutils, will not be able to build text output.')
    paverutils.run_sphinx(options, 'text')
    return

@task
@needs(['generate_setup', 
        'minilib', 
        'cog',
        'html_clean', 
        #'text',
        'setuptools.command.sdist',
        ])
def sdist(options):
    """Create a source distribution.
    """
    # Move the output file to the desktop
    dist_files = path('dist').glob('*.tar.gz')
    dest_dir = path(options.sdistext.outdir).expanduser()
    for f in dist_files:
        dest_file = dest_dir / f.basename()
        dest_file.unlink()
        f.move(dest_dir)
    
    sh('growlnotify -m "package built"')
    return

@task
def html_clean(options):
    """Remove sphinx output directories before building the HTML.
    """
    remake_directories(options.sphinx.doctrees, options.html.outdir)
    html(options)
    return

def set_templates(template_name):
    """Set the TEMPLATES environment variable, used by sphinx/conf.py.
    """
    os.environ['TEMPLATES'] = template_name
    print 'Set TEMPLATES = "%s"' % template_name
    return

@task
def pdf():
    """Generate the PDF book.
    """
    set_templates(options.pdf.templates)
    if paverutils is None:
        raise RuntimeError('Could not find sphinxcontrib.paverutils, will not be able to build PDF output.')
    paverutils.pdf(options)
    return

@task
def website(options):
    """Create local copy of website files.
    """
    pdf(options)
    webhtml(options)
    # Copy the PDF to the files to be copied to the directory to install
    pdf_file = path(options.pdf.builddir) / 'latex' / (PROJECT + '-' + VERSION + '.pdf')
    pdf_file.copy(path(options.website.builddir) / 'html')
    return

@task
def installwebsite(options):
    """Rebuild and copy website files to the remote server.
    """
    # Clean up
    remake_directories(options.pdf.builddir, options.website.builddir)
    # Rebuild
    website(options)
    # Install
    rsyncwebsite(options)
    return
    
@task
def rsyncwebsite(options):
    # Copy to the server
    os.environ['RSYNC_RSH'] = '/usr/bin/ssh'
    src_path = path(options.website.builddir) / 'html'
    sh('(cd %s; rsync --archive --delete --verbose . %s:%s)' % 
        (src_path, options.website.server, options.website.server_path))
    return

@task
def webtemplatebase():
    """Import the latest version of the web page template from the source.
    """
    dest = path(options.website.template_dest).expanduser()
    src = path(options.website.template_source).expanduser()
    if not dest.exists() or (src.mtime > dest.mtime):
        src.copy(dest)
    return

@task
@needs(['webtemplatebase'])
def webhtml(options):
    """Generate HTML files for website.
    """
    set_templates(options.website.templates)
    if paverutils is None:
        raise RuntimeError('Could not find sphinxcontrib.paverutils, will not be able to build HTML output.')
    paverutils.run_sphinx(options, 'website')
    sitemap_gen()
    return

@task
def sitemap_gen():
    sh('sitemap_gen.py --testing --config=%s' % options.sitemap_gen.config)
    return
            

def get_post_title(filename):
    f = open(filename, 'rt')
    try:
        body = f.read()
    finally:
        f.close()

    # Clean up the HTML
    from BeautifulSoup import BeautifulSoup, Tag

    # The post body is passed to stdin.
    soup = BeautifulSoup(body)

    # Get the heading(s)
    h1 = soup.find('h1')

    # Get BeautifulSoup's version of the string
    #title = ' '.join(h1.string)
    title = ' '.join(s for s in h1 if type(s) != Tag)

    return title


def gen_blog_post(outdir, input_base, blog_base, url_base):
    """Generate the blog post body.
    """
    outdir = path(outdir)
    input_file = outdir / input_base
    blog_file = outdir/ blog_base
    
    canonical_url = "http://www.doughellmann.com/" + url_base
    if not canonical_url.endswith('/'):
        canonical_url += '/'
    if input_base != "index.html":
        canonical_url += input_base

    module_name = MODULE
    title = '%s - ' % module_name

    # Get the intro paragraph
    from BeautifulSoup import BeautifulSoup, Tag
    raw_body = input_file.text().strip()
    soup = BeautifulSoup(raw_body)
    intro = soup.find('p')

    # Strip hyperlinks by replacing those nodes with their contents.
    for link in intro.findAll('a'):
        new_span = Tag(soup, 'span')
        for c in link.contents:
            new_span.append(c)
        link.replaceWith(new_span)

    output_body = '''%(intro)s
<p><a href="%(canonical_url)s">Read more...</a></p>
''' % locals()
    blog_file.write_text(output_body)

    home_page_reference = '''<p><a class="reference external" href="http://www.doughellmann.com/PyMOTW/">PyMOTW Home</a></p>'''
    canonical_reference = '''<p>The <a class="reference external" href="%(canonical_url)s">canonical version</a> of this article</p>''' % locals()
    
    blog_file.write_text(output_body)
    return

@task
@cmdopts([
    ('in-file=', 'b', 'Blog input filename (e.g., "-b index.html")'),
    ('out-file=', 'B', 'Blog output filename (e.g., "-B blog.html")'),
    ('sourcedir=', 's', 'Source directory name (e.g., "-s PyMOTW/articles")'),
    ('no-edit', 'n', 'Do not open the post in an editor'),
])
def blog(options):
    """Generate the blog post version of the HTML for the current module.
    
    The default behavior generates the post for the current module using 
    its index.html file as input.
    
    To use a different file within the module directory, use the 
    --in-file or -b option::
    
      paver blog -b communication.html
      
    To run against a directory other than a module, use the 
    -s or --sourcedir option::
    
      paver blog -s PyMOTW/articles -b text_processing.html
    """    
    # Clean and recreate output directory
    remake_directories(options.blog.outdir)
    
    # Generate html from sphinx
    if paverutils is None:
        raise RuntimeError('Could not find sphinxcontrib.paverutils, will not be able to build HTML output.')
    paverutils.run_sphinx(options, 'blog')
    
    blog_file = path(options.blog.outdir) / options.blog.out_file
    dry("Write blog post body to %s" % blog_file, 
        gen_blog_post, 
        outdir=options.blog.outdir, 
        input_base=options.blog.in_file, 
        blog_base=options.blog.out_file,
        url_base=options.blog.sourcedir,
        )

    title = get_post_title(path(options.blog.outdir) / options.blog.in_file)
    
    if not options.no_edit:
        if os.path.exists('bin/SendToMarsEdit.applescript'):
            sh('osascript bin/SendToMarsEdit.applescript "%s" "%s"' % 
                (blog_file, "PyMOTW: %s" % title)
                )

        elif 'EDITOR' in os.environ:
            sh('$EDITOR %s' % blog_file)
    return
    

@task
@needs(['uncog'])
def commit():
    """Commit the changes to hg.
    """
    sh('hg commit')
    return

@task
@needs(['uncog'])
def bitbucket_push(options):
    sh('hg push')
    return

@task
def release(options):
    """Run the automatable steps of the release process."""
    sdist(options)
    installwebsite(options)
    blog(options)
    bitbucket_push(options)
    print 'NEXT: upload package, "paver register", post to blog'
    return

@task
def checklist(options):
    """Show the release checklist.
    """
    print """
Checklist
=========    

- hg pull into src sandbox
- Change version in pavement.py
- Update history file
- hg commit
- hg tag
- paver sdist
- Upload package
- paver installwebsite
- paver register
- paver blog
- Post to blog
- Post to O'Reilly
- hg push from src to bitbucket
    """


From pje at telecommunity.com  Wed Sep  8 18:56:01 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 08 Sep 2010 12:56:01 -0400
Subject: [Distutils] problem with sdist for nested packages
In-Reply-To: <A1B4B710-343C-486C-A454-B62BA5738F75@gmail.com>
References: <29EAA4F4-F241-4A29-A3F4-08FEFDD406C3@gmail.com>
	<4C877584.3050109@trueblade.com>
	<A1B4B710-343C-486C-A454-B62BA5738F75@gmail.com>
Message-ID: <20100908165600.4063C3A4100@sparrow.telecommunity.com>

At 12:00 PM 9/8/2010 -0400, Doug Hellmann wrote:
>Instead of explicitly listing packages, I use find_package_data() 
>and then get the package names from that result.  The odd thing is I 
>get a package "PyMOTW.ElementTree" but not 
>"PyMOTW.xml.etree.ElementTree".  Maybe I'm misunderstanding/misusing 
>find_package_data(), since that nested package is the only one I'm 
>having problems with.

You want find_packages():

http://peak.telecommunity.com/DevCenter/setuptools#using-find-packages



From doug.hellmann at gmail.com  Wed Sep  8 22:03:30 2010
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Wed, 8 Sep 2010 16:03:30 -0400
Subject: [Distutils] problem with sdist for nested packages
In-Reply-To: <20100908165600.4063C3A4100@sparrow.telecommunity.com>
References: <29EAA4F4-F241-4A29-A3F4-08FEFDD406C3@gmail.com>
	<4C877584.3050109@trueblade.com>
	<A1B4B710-343C-486C-A454-B62BA5738F75@gmail.com>
	<20100908165600.4063C3A4100@sparrow.telecommunity.com>
Message-ID: <1940EB32-B655-4C83-B84B-320B0758A536@gmail.com>


On Sep 8, 2010, at 12:56 PM, P.J. Eby wrote:

> At 12:00 PM 9/8/2010 -0400, Doug Hellmann wrote:
>> Instead of explicitly listing packages, I use find_package_data() and then get the package names from that result.  The odd thing is I get a package "PyMOTW.ElementTree" but not "PyMOTW.xml.etree.ElementTree".  Maybe I'm misunderstanding/misusing find_package_data(), since that nested package is the only one I'm having problems with.
> 
> You want find_packages():
> 
> http://peak.telecommunity.com/DevCenter/setuptools#using-find-packages

Thanks, I'll give that a try.

Doug


From doug.hellmann at gmail.com  Thu Sep  9 12:38:22 2010
From: doug.hellmann at gmail.com (Doug Hellmann)
Date: Thu, 9 Sep 2010 06:38:22 -0400
Subject: [Distutils] problem with sdist for nested packages
In-Reply-To: <20100908165600.4063C3A4100@sparrow.telecommunity.com>
References: <29EAA4F4-F241-4A29-A3F4-08FEFDD406C3@gmail.com>
	<4C877584.3050109@trueblade.com>
	<A1B4B710-343C-486C-A454-B62BA5738F75@gmail.com>
	<20100908165600.4063C3A4100@sparrow.telecommunity.com>
Message-ID: <B3D2DADF-CB3A-4903-919A-547E042A68E2@gmail.com>


On Sep 8, 2010, at 12:56 PM, P.J. Eby wrote:

> At 12:00 PM 9/8/2010 -0400, Doug Hellmann wrote:
>> Instead of explicitly listing packages, I use find_package_data() and then get the package names from that result.  The odd thing is I get a package "PyMOTW.ElementTree" but not "PyMOTW.xml.etree.ElementTree".  Maybe I'm misunderstanding/misusing find_package_data(), since that nested package is the only one I'm having problems with.
> 
> You want find_packages():
> 
> http://peak.telecommunity.com/DevCenter/setuptools#using-find-packages

That took care of it. Thanks for the help!

Doug


From manlio.perillo at gmail.com  Thu Sep  9 19:37:28 2010
From: manlio.perillo at gmail.com (Manlio Perillo)
Date: Thu, 09 Sep 2010 19:37:28 +0200
Subject: [Distutils] bdist_wininst and dependencies with setuptools
Message-ID: <4C891B58.8010403@gmail.com>

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

Hi.

Today I was building a package that must be installed on a Windows
system (I'm on Linux).

I simply did:
python setup.py bdist_inst

and I was expecting that, when executed on the Windows machine, it would
not only install my package, but also all dependencies declared in the
setup file.

This was not the case.

I would like to avoid having to create an all in one installer using
pyinstalled; is this possible?

Note that dependencies are all pure Python modules available on pypi,
except PyQt (that is installed using the installer provided by riverbank).



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

iEYEARECAAYFAkyJG1gACgkQscQJ24LbaUTcCgCfRFOCF101mhRfaWCuU+5g41Wj
X2EAn2tOiYudntVi06aa9L9IdpNxp5y2
=YiSl
-----END PGP SIGNATURE-----

From pje at telecommunity.com  Thu Sep  9 23:03:10 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 09 Sep 2010 17:03:10 -0400
Subject: [Distutils] bdist_wininst and dependencies with setuptools
In-Reply-To: <4C891B58.8010403@gmail.com>
References: <4C891B58.8010403@gmail.com>
Message-ID: <20100909210309.A307C3A4069@sparrow.telecommunity.com>

At 07:37 PM 9/9/2010 +0200, Manlio Perillo wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi.
>
>Today I was building a package that must be installed on a Windows
>system (I'm on Linux).
>
>I simply did:
>python setup.py bdist_inst
>
>and I was expecting that, when executed on the Windows machine, it would
>not only install my package, but also all dependencies declared in the
>setup file.
>
>This was not the case.
>
>I would like to avoid having to create an all in one installer using
>pyinstalled; is this possible?

No; bdist_wininst doesn't support dependencies.  If you need Windows 
users to install dependencies, they'll have to use 
easy_install.  (I'd say "or pip", but pip doesn't support installing 
pre-built binaries.)


>Note that dependencies are all pure Python modules available on pypi,
>except PyQt (that is installed using the installer provided by riverbank).

If everything but PyQt is pure python, then you can just have them 
install from source using pip or easy_install.  (Or, alternatively, 
build an executable with py2exe.)


From pje at telecommunity.com  Fri Sep 10 04:13:31 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 09 Sep 2010 22:13:31 -0400
Subject: [Distutils] bdist_wininst and dependencies with setuptools
In-Reply-To: <4C89559C.7080905@gmail.com>
References: <4C891B58.8010403@gmail.com>
	<20100909210309.A307C3A4069@sparrow.telecommunity.com>
	<4C89559C.7080905@gmail.com>
Message-ID: <20100910021331.09C373A4069@sparrow.telecommunity.com>

At 11:46 PM 9/9/2010 +0200, Manlio Perillo wrote:
>Il 09/09/2010 23:03, P.J. Eby ha scritto:
> > At 07:37 PM 9/9/2010 +0200, Manlio Perillo wrote:
> >> I would like to avoid having to create an all in one installer using
> >> pyinstalled; is this possible?
> >
> > No; bdist_wininst doesn't support dependencies.
>
>Is this hard to implement?

Well, you'd need to write some C code, or else implement something in 
a Python post-install script.  I'm not sure how difficult that would 
be, but it's more effort than I'd personally like to put in.

>What about distutils2?

I don't know if they're working on that.


> >  If you need Windows
> > users to install dependencies, they'll have to use easy_install.  (I'd
> > say "or pip", but pip doesn't support installing pre-built binaries.)
> >
>
>Using easy_install still requires the user to open the command prompt,
>locate where the easy_install.exe is installed, and run it.
>
>This is what I would like to avoid.

Then py2exe or some other sort of installer is probably your best bet. 


From manlio.perillo at gmail.com  Fri Sep 10 13:24:12 2010
From: manlio.perillo at gmail.com (Manlio Perillo)
Date: Fri, 10 Sep 2010 13:24:12 +0200
Subject: [Distutils] bdist_wininst and dependencies with setuptools
In-Reply-To: <20100910021331.09C373A4069@sparrow.telecommunity.com>
References: <4C891B58.8010403@gmail.com>
	<20100909210309.A307C3A4069@sparrow.telecommunity.com>
	<4C89559C.7080905@gmail.com>
	<20100910021331.09C373A4069@sparrow.telecommunity.com>
Message-ID: <4C8A155C.1070608@gmail.com>

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

Il 10/09/2010 04:13, P.J. Eby ha scritto:
> At 11:46 PM 9/9/2010 +0200, Manlio Perillo wrote:
>> Il 09/09/2010 23:03, P.J. Eby ha scritto:
>> > At 07:37 PM 9/9/2010 +0200, Manlio Perillo wrote:
>> >> I would like to avoid having to create an all in one installer using
>> >> pyinstalled; is this possible?
>> >
>> > No; bdist_wininst doesn't support dependencies.
>>
>> Is this hard to implement?
> 
> Well, you'd need to write some C code, or else implement something in a
> Python post-install script.  I'm not sure how difficult that would be,
> but it's more effort than I'd personally like to put in.
> 

I will try something using the post-install script; as an example
executing `setup.py install` from it.

By the way, is it possible, from the postinstall script, to know the
Python instance used?
I need it because I would like to create a shortcut of a script to the
desktop, and I need to know the full path of the script.



>> What about distutils2?
> 
> I don't know if they're working on that.
> 

There is one thing I'm not sure to understand about the bdist_wininst
and bdist_msi commands: what is the reason why they don't simply execute
`python setup.py install` in the background?

> [...]
>
> Then py2exe or some other sort of installer is probably your best bet.
> 

I will do some tests to see if it works without too many problems.



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

iEYEARECAAYFAkyKFVwACgkQscQJ24LbaUTPaACfYYWY4rD3yIRyyXT5lPvmqKuu
4DUAnjgI7kfuHSsjydgPkeAsLW1BmRlo
=ZcfI
-----END PGP SIGNATURE-----

From chris at simplistix.co.uk  Fri Sep 10 15:52:15 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 10 Sep 2010 14:52:15 +0100
Subject: [Distutils] equivalent of --tag-svn-revision for mercurial?
Message-ID: <4C8A380F.9000306@simplistix.co.uk>

Hi All,

Is there any equivalent of --tag-svn-revision for Mercurial?

cheers,

Chris


From pje at telecommunity.com  Fri Sep 10 16:04:49 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 10 Sep 2010 10:04:49 -0400
Subject: [Distutils] equivalent of --tag-svn-revision for mercurial?
In-Reply-To: <4C8A380F.9000306@simplistix.co.uk>
References: <4C8A380F.9000306@simplistix.co.uk>
Message-ID: <20100910140451.46B423A408F@sparrow.telecommunity.com>

At 02:52 PM 9/10/2010 +0100, Chris Withers wrote:
>Hi All,
>
>Is there any equivalent of --tag-svn-revision for Mercurial?

Not really, since hg doesn't really have a serially increasing commit 
number.  There is a mercurial plugin for setuptools that supports 
versioning from tags, though:

    http://pypi.python.org/pypi/hgtools

With non-SVN source control, you're pretty much stuck using dates as 
pseudo-serial numbers. 


From gary.poster at canonical.com  Fri Sep 10 20:10:38 2010
From: gary.poster at canonical.com (Gary Poster)
Date: Fri, 10 Sep 2010 14:10:38 -0400
Subject: [Distutils] Buildout release news
In-Reply-To: <AANLkTi=Kcvq7yfqjChnzEXXsuVSxLjx2iOusmnS440DO@mail.gmail.com>
References: <E025916A-57C9-437B-8C2C-4A0EA0AE4D16@canonical.com>
	<i50an3$96j$1@dough.gmane.org> <i50l08$ocb$1@dough.gmane.org>
	<C50784F5-855F-4FC4-878A-7CB9008A6591@canonical.com>
	<i52p1e$dur$1@dough.gmane.org>
	<19BF88C4-9AE3-46B0-BBCE-6115F4A4C625@canonical.com>
	<4C777604.6050509@vanrees.org>
	<94B2F054-FA29-430B-94B1-AAB2B04F748F@canonical.com>
	<i595eh$mir$1@dough.gmane.org>
	<DBC5D05C-3DDD-4B63-BA9B-4A2513057C93@canonical.com>
	<AANLkTimQkW=rMESbZg9Xq3rxWre0cFwLtnEGYoTg3n1b@mail.gmail.com>
	<0F06B2EA-7DD5-4280-825F-83F01AA2BA86@canonical.com>
	<AANLkTi=Kcvq7yfqjChnzEXXsuVSxLjx2iOusmnS440DO@mail.gmail.com>
Message-ID: <9E3BBA8A-6C09-4AF1-A579-6B118531E7E4@canonical.com>


On Aug 30, 2010, at 5:17 PM, Jim Fulton wrote:

> On Mon, Aug 30, 2010 at 3:06 PM, Gary Poster <gary.poster at canonical.com> wrote:
>> 
>> On Aug 30, 2010, at 1:50 PM, Jim Fulton wrote:
> 
> ...
> 
>>> My preferance is that buildout provide isolated and non-isolated modes
>>> and that the isolation apply equally to recipes, extensions, and eggs
>>> installed by parts.

I have a branch that I've asked Reinout to test that does this.  Defaulting to non-isolated should significantly increase backwards compatibility.

I'll hope to release a 1.5.2 with this next week.  It will also have some other bugfixes found along the way, and maybe some Mac support (turns out the Mac system Python does something weird and different itself).

>> Having fought through all this, I really think having separate
>  isolation controls for the buildout (buildout, recipes, extensions)
>  versus the things that are built by parts is the right way to
>  go.  It's two very different domains, and the people writing the
>  two kinds of code are often completely separate.
> 
> I don't want to make work for you, but I don't understand what issues
> you fought.  Are there any links you can give that might allow me to
> get this for myself?

I talked to Jim after this email, and my answer was essentially, "No.  Maybe I was just tired fighting generally and gave up too easily."

Gary

From manlio.perillo at gmail.com  Sat Sep 11 16:42:40 2010
From: manlio.perillo at gmail.com (Manlio Perillo)
Date: Sat, 11 Sep 2010 16:42:40 +0200
Subject: [Distutils] [ANN] setuptools post install script for bdist_wininst
Message-ID: <4C8B9560.9000702@gmail.com>

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

Hi.

Following the suggestion to use a post installation script in order to
install dependencies for a package installed using bdist_wininst, I
wrote this reusable script:

http://paste.pocoo.org/show/260644/


In order to use it, the script must be declared as a script in the
setup.py file.
In order to ensure setuptools is installed, the same should be do with
the ez_setup bootstrap script.

The ez_post_install script will do:

1) Get the installed project name by parsing the bdist_wininst file name
2) Make sure setuptools is installed (if ez_setup is available)
3) Install all dependencies of the installed package, using easy_install
4) Optionally add shortcuts of all gui scripts in the
   Start Menu\Programs\<project name> special folder
5) Optionally add shortcuts of all gui scripts in the Desktop


Problems
========

Since the post install script may take some time downloading and
installing packages, the UI of the Windows installer is frozen, without
giving user any feedback.
This is a problem with the installer, since stdout and stderr are fully
buffered.

TODO
====

In case a dependency have extension code that must compiled, in 99% of
the cases the post install script will fail, since the compiler or some
library is not available.

This should not happen; the post install script should, instead, check
if in the package download_url there is a bdist_wininst executable,
download it and execute it.



Suggestions are welcome.


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

iEYEARECAAYFAkyLlWAACgkQscQJ24LbaURBJwCgkU87bIiGGt2uj3qBcxZ1NIS6
07AAn2mXk9kQvtjgEXtWb3uwiQT69mwZ
=l8M2
-----END PGP SIGNATURE-----

From pje at telecommunity.com  Sat Sep 11 20:10:11 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 11 Sep 2010 14:10:11 -0400
Subject: [Distutils] [ANN] setuptools post install script for
 bdist_wininst
In-Reply-To: <4C8B9560.9000702@gmail.com>
References: <4C8B9560.9000702@gmail.com>
Message-ID: <20100911181015.08BE23A4069@sparrow.telecommunity.com>

At 04:42 PM 9/11/2010 +0200, Manlio Perillo wrote:
>This is a problem with the installer, since stdout and stderr are fully
>buffered.

You probably need to pop up some sort of dialog and direct 
stdout/stderr there.  Alternately, you could run easy_install in a 
separate process as a console script.


>TODO
>====
>
>In case a dependency have extension code that must compiled, in 99% of
>the cases the post install script will fail, since the compiler or some
>library is not available.
>
>This should not happen; the post install script should, instead, check
>if in the package download_url there is a bdist_wininst executable,
>download it and execute it.

easy_install already does this, sort of: it downloads bdist_wininst 
executables and converts them into eggs, then installs the eggs.


>Suggestions are welcome.

In general, I'm not sure that this sort of thing is wise to do in a 
bdist_wininst postinstall without some kind of user prompting, since:

1. A primary reason people have for using bdist_wininst installers is 
uninstall support, and this approach will leave dependencies behind.

2. Another big reason people have for using these installers instead 
of easy_install is that they don't want things being downloaded from 
the net, because e.g. they have no access or are behind a proxy, so 
this is just going to annoy them.

I would strongly recommend having some sort of dialog that simply 
tells the user what dependencies are missing, and then asks if they 
would like to have them installed automatically.  (So the user can 
then say no if they need uninstallability or have limited network access.)


From manlio.perillo at gmail.com  Sat Sep 11 21:48:57 2010
From: manlio.perillo at gmail.com (Manlio Perillo)
Date: Sat, 11 Sep 2010 21:48:57 +0200
Subject: [Distutils] [ANN] setuptools post install script for
	bdist_wininst
In-Reply-To: <20100911181015.08BE23A4069@sparrow.telecommunity.com>
References: <4C8B9560.9000702@gmail.com>
	<20100911181015.08BE23A4069@sparrow.telecommunity.com>
Message-ID: <4C8BDD29.5030505@gmail.com>

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

Il 11/09/2010 20:10, P.J. Eby ha scritto:
> At 04:42 PM 9/11/2010 +0200, Manlio Perillo wrote:
>> This is a problem with the installer, since stdout and stderr are fully
>> buffered.
> 
> You probably need to pop up some sort of dialog and direct stdout/stderr
> there. 

Not easy, but I will give it a try.

> Alternately, you could run easy_install in a separate process as
> a console script.
> 
> 
>> TODO
>> ====
>>
>> In case a dependency have extension code that must compiled, in 99% of
>> the cases the post install script will fail, since the compiler or some
>> library is not available.
>>
>> This should not happen; the post install script should, instead, check
>> if in the package download_url there is a bdist_wininst executable,
>> download it and execute it.
> 
> easy_install already does this, sort of: it downloads bdist_wininst
> executables and converts them into eggs, then installs the eggs.
> 

Sorry, I was referring to "all in one" installers, that is, installers
that also install external shared libraries.

As an example:
http://www.riverbankcomputing.com/static/Downloads/PyQt4/PyQt-Py2.6-gpl-4.7.6-1.exe

The PyQt4 installer put external DLLs (and some executables like
designer.exe) in
C:\Python26\Lib\site-packages\PyQt4\bin

Is it possible to put required DLLs inside an egg?
For PyQt4 there seems to be only the "all in one" installers and source
distributions.

I'm also having some issues with PyQt4 and easy_install.

> 
>> Suggestions are welcome.
> 
> In general, I'm not sure that this sort of thing is wise to do in a
> bdist_wininst postinstall without some kind of user prompting, since:
> 
> 1. A primary reason people have for using bdist_wininst installers is
> uninstall support, and this approach will leave dependencies behind.
> 

As far as I know, all dependencies are correctly handled.
Shortcuts are correctly removed by the uninstall.

> 2. Another big reason people have for using these installers instead of
> easy_install is that they don't want things being downloaded from the
> net, because e.g. they have no access or are behind a proxy, so this is
> just going to annoy them.
> 

For me the main reason is the problem users have at using the command
prompt and setting environment variables.
easy_install is perfectly fine, IMHO, it only needs an usable GUI for
Windows.

I recently discovered that ActivePython have PyPM.
I will do some tests.

> I would strongly recommend having some sort of dialog that simply tells
> the user what dependencies are missing, and then asks if they would like
> to have them installed automatically.  (So the user can then say no if
> they need uninstallability or have limited network access.)
> 

Thanks for the suggestion.

By the way, I tried to install pywin32, but I got:

C:\>easy_install pywin32
Searching for pywin32
Reading http://pypi.python.org/simple/pywin32/
Reading http://sf.net/projects/pywin32
Reading http://sourceforge.net/project/showfiles.php?group_id=78018
Best match: pywin32 214
Downloading
http://sourceforge.net/projects/pywin32/files/pywin32/Build%20214/py
win32-214.win32-py2.6.exe/download
Processing download
error: Couldn't find a setup script in
c:\docume~1\manlio\impost~1\temp\easy_install-ni9nay\download


It is also strange that path components are also reported using short
names...



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

iEYEARECAAYFAkyL3SgACgkQscQJ24LbaUQEqgCglYphT5RQU1XBRN0dXuedqamx
LgsAoIgsKfZsKzeygpvwP79uWVxmkSHX
=B/Zu
-----END PGP SIGNATURE-----

From pje at telecommunity.com  Sat Sep 11 23:22:15 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 11 Sep 2010 17:22:15 -0400
Subject: [Distutils] [ANN] setuptools post install script for
 bdist_wininst
In-Reply-To: <4C8BDD29.5030505@gmail.com>
References: <4C8B9560.9000702@gmail.com>
	<20100911181015.08BE23A4069@sparrow.telecommunity.com>
	<4C8BDD29.5030505@gmail.com>
Message-ID: <20100911212230.68E693A4069@sparrow.telecommunity.com>

At 09:48 PM 9/11/2010 +0200, Manlio Perillo wrote:
>Is it possible to put required DLLs inside an egg?

Yes, but they have to be adjacent to any Python extensions (.pyd's) 
that use them.

> > 1. A primary reason people have for using bdist_wininst installers is
> > uninstall support, and this approach will leave dependencies behind.
> >
>
>As far as I know, all dependencies are correctly handled.
>Shortcuts are correctly removed by the uninstall.

But the dependencies installed by easy_install will not get 
corresponding uninstall entries in the Windows control panel, and so 
will not be uninstalled when the user uninstalls the main application 
or library.


>By the way, I tried to install pywin32, but I got:

AFAIK, pywin32 is not easy_install-able due to some post-install 
incompatibilities.


From jim at zope.com  Sun Sep 12 10:59:19 2010
From: jim at zope.com (Jim Fulton)
Date: Sun, 12 Sep 2010 04:59:19 -0400
Subject: [Distutils] Buildout release news
In-Reply-To: <9E3BBA8A-6C09-4AF1-A579-6B118531E7E4@canonical.com>
References: <E025916A-57C9-437B-8C2C-4A0EA0AE4D16@canonical.com>
	<i50an3$96j$1@dough.gmane.org> <i50l08$ocb$1@dough.gmane.org>
	<C50784F5-855F-4FC4-878A-7CB9008A6591@canonical.com>
	<i52p1e$dur$1@dough.gmane.org>
	<19BF88C4-9AE3-46B0-BBCE-6115F4A4C625@canonical.com>
	<4C777604.6050509@vanrees.org>
	<94B2F054-FA29-430B-94B1-AAB2B04F748F@canonical.com>
	<i595eh$mir$1@dough.gmane.org>
	<DBC5D05C-3DDD-4B63-BA9B-4A2513057C93@canonical.com>
	<AANLkTimQkW=rMESbZg9Xq3rxWre0cFwLtnEGYoTg3n1b@mail.gmail.com>
	<0F06B2EA-7DD5-4280-825F-83F01AA2BA86@canonical.com>
	<AANLkTi=Kcvq7yfqjChnzEXXsuVSxLjx2iOusmnS440DO@mail.gmail.com>
	<9E3BBA8A-6C09-4AF1-A579-6B118531E7E4@canonical.com>
Message-ID: <AANLkTikuNMzKsHhrfTTksd4VDqXkzM4dzuv5UJy7NUc0@mail.gmail.com>

On Fri, Sep 10, 2010 at 2:10 PM, Gary Poster <gary.poster at canonical.com> wrote:
...
> turns out the Mac system Python does something weird and different itself

I'm shocked, shocked! ;)

Jim

-- 
Jim Fulton

From techtonik at gmail.com  Sun Sep 12 11:08:59 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Sun, 12 Sep 2010 12:08:59 +0300
Subject: [Distutils] please fix easy_install shorter URL preference (Was:
 easy_install wrong download site preference)
Message-ID: <AANLkTi=LJ-JrfXTmZzpuCjxnmY=SZH1bhbNTnkEXMpCW@mail.gmail.com>

Hello Phillip,

Again, I've run into completely irrational 'easy_install' behavior
that prefers to download from shorter URLs instead of PyPI ones if the
same filename exists in both places. `protobuf` project and `gerald`
are not installable due to this behavior.

http://code.google.com/p/protobuf/issues/detail?id=66
https://sourceforge.net/apps/trac/halfcooked/ticket/29

Gerald is the second package from the last 4 months that I couldn't
install due to this very obscure behavior, and I suspect there are
more.


Phillip, could you, please, still run through your archives to success
in explaining why this logic of choosing a shorter download URL is
necessary? I'd really to see what packages benefit from it, because I
believe Google protocol buffers popularity alone is enough to change
the behavior.

Thanks.
-- 
anatoly t.



On Fri, Jul 2, 2010 at 5:06 AM, P.J. Eby <pje at telecommunity.com> wrote:
> At 01:33 AM 7/2/2010 +0300, anatoly techtonik wrote:
>>
>> On Fri, Jul 2, 2010 at 12:10 AM, P.J. Eby <pje at telecommunity.com> wrote:
>> >> >
>> >> > It prefers newer packages, or, if the versions are the same, it
>> >> > prefers
>> >> > the shortest download URL. ?? In this case, the Google Code url is
>> >> > shorter.
>> >>
>> >> That's illogical. Better prefer PyPI if versions are the same.
>> >
>> > The "shortest path" logic is there to avoid certain file recognition
>> > problems that occur without it. ? The special case of PyPI isn't special
>> > enough to break those rules.
>>
>> Although practicality beats purity. Can you list those "certain file
>> recognition problems"? I.e. Explicit is better than implicit.
>
> I have a vague recollection that it was Fredrik Lundh's website that sparked
> the original realization of the need for preferring shorter URLs, but I
> wouldn't swear to it. ?I'd have to dig through years of revision history to
> find the original change, assuming I documented it well enough. ?The choice
> of short paths over long was also intended to favor nearby files over
> further ones, and local paths over URLs.
>
> (All that being said, it's still fundamentally a heuristic, and not a very
> good one at that. ?But that doesn't automatically make any other heuristic
> *better*; this is one area where status quo bias is a good thing.)
>
>
>> That's why it should use the site where all filenames are Python
>> downloads if filenames are the same.
>
> And how would that work with all the PyPI clones, private indexes, etc.?
>
>
>> > No. ? You'd need to remove the current "home_page" setting, or point it
>> > elsewhere.
>>
>> That's very strange. Then what download_url is for?
>
> The home page and download URLs are simply treated as pages which may
> contain links to files, if they are not themselves links to files. ?That's
> the only special status they have.
>
>
>> >> ? (I understand that people do not want to touch setuptools code
>> >> anymore)
>> >
>> > That's not really the issue; the issue here is that package precedence
>> > is
>> > based on a stable comparison scheme, where it doesn't make sense to give
>> > one
>> > location priority over another, as it will simply lead to someone else
>> > complaining about the changed behavior, because they were relying on a
>> > different URL having precedence under the current scheme.
>>
>> These rules need to be described first. What if somebody already broke
>> the proper order and now everybody suffers? If autodiscovery rules
>> were well described - it was possible to analyse them and propose more
>> intuitive approach. Then if "someone else" will attempt to complain -
>> you could send them to the PEP or another "how and why" document.
>
> http://peak.telecommunity.com/DevCenter/setuptools#making-your-package-available-for-easyinstall
>
> http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
>
>
>> I thought it will raise the weight of those links if there could be a
>> rel="download" attribute.
>
> There is no "weighting" of links - what is weighted are distributions, and
> distribution objects only have their raw URL available as a basis for
> sorting once the version and archive type (the two higher-precedence
> attributes) are considered. ?The place where a URL was retrieved from is not
> tracked, and thus can't be used for sorting without a good chunk of
> refactoring... ?which refactoring would likely break tools that build on top
> of setuptools' PackageIndex class.
>
> In short, what you're asking for is a pretty major feature that would be
> difficult to implement in a way that would be guaranteed not to break other
> things.
>
>

From manlio.perillo at gmail.com  Sun Sep 12 14:05:22 2010
From: manlio.perillo at gmail.com (Manlio Perillo)
Date: Sun, 12 Sep 2010 14:05:22 +0200
Subject: [Distutils] [ANN] setuptools post install script for
	bdist_wininst
In-Reply-To: <20100911181015.08BE23A4069@sparrow.telecommunity.com>
References: <4C8B9560.9000702@gmail.com>
	<20100911181015.08BE23A4069@sparrow.telecommunity.com>
Message-ID: <4C8CC202.3060305@gmail.com>

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

Il 11/09/2010 20:10, P.J. Eby ha scritto:
> At 04:42 PM 9/11/2010 +0200, Manlio Perillo wrote:
>> This is a problem with the installer, since stdout and stderr are fully
>> buffered.
> 
> You probably need to pop up some sort of dialog and direct stdout/stderr
> there.  Alternately, you could run easy_install in a separate process as
> a console script.
> 

By the way, I'm not sure to understand how running easy_install in a
separate process would solve the installer GUI freeze problem.

It should probably be the installer to execute the post install script
in non blocking mode.


> [...]


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

iEYEARECAAYFAkyMwgIACgkQscQJ24LbaUScqQCeK3I7cXfDfuhrdytBmbSuA2bI
/QsAoJW1pBgchIjOPvi/S5+TMQHd+I+d
=KuaC
-----END PGP SIGNATURE-----

From manlio.perillo at gmail.com  Sun Sep 12 14:36:27 2010
From: manlio.perillo at gmail.com (Manlio Perillo)
Date: Sun, 12 Sep 2010 14:36:27 +0200
Subject: [Distutils] [ANN] setuptools post install script for
	bdist_wininst
In-Reply-To: <20100911212230.68E693A4069@sparrow.telecommunity.com>
References: <4C8B9560.9000702@gmail.com>
	<20100911181015.08BE23A4069@sparrow.telecommunity.com>
	<4C8BDD29.5030505@gmail.com>
	<20100911212230.68E693A4069@sparrow.telecommunity.com>
Message-ID: <4C8CC94B.4000806@gmail.com>

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

Il 11/09/2010 23:22, P.J. Eby ha scritto:
> At 09:48 PM 9/11/2010 +0200, Manlio Perillo wrote:
>> Is it possible to put required DLLs inside an egg?
> 
> Yes, but they have to be adjacent to any Python extensions (.pyd's) that
> use them.
> 

Good to know, thanks.

But how can I create such a egg?
And if this is possible, what do you think is the reasons why packages
like pyqt do not release such eggs?


>> > 1. A primary reason people have for using bdist_wininst installers is
>> > uninstall support, and this approach will leave dependencies behind.
>> >
>>
>> As far as I know, all dependencies are correctly handled.
>> Shortcuts are correctly removed by the uninstall.
> 
> But the dependencies installed by easy_install will not get
> corresponding uninstall entries in the Windows control panel, and so
> will not be uninstalled when the user uninstalls the main application or
> library.
> 

Ah, right; I was thinking to created shortcuts.

It should not be hard to track installed dependencies, as an example
using the --record option of easy_install, and then registering all
installed files (and directories) with `file_created` and
`directory_created` functions.

The only problem is that created directories are not reported in the
record, but if files are always listed ordered, it should not be a problem.


Some other related questions:

* Do you think you can change ez_setup.py so that the code used to
  check if setuptools must be installed is available as a separate
  function?

  I need to check if setuptools must be installed so that I can pop a
  message box.
  For normal package dependencies (and assuming setuptools is
  available) I can just use working_set.__contains__(dist)

* Is it safe to call `ez_setup.use_setuptools` setting `to_dir`
  parameter to `sysconfig.get_python_lib()`?

  By default the setuptools egg is copied to the same directory where
  the bdist_wininst file is, and this is not safe since the user may
  delete these files.

* Is it possible to get the ID of the main window of the bdist_wininst
  application?
  I need it because MessageBox function requires the ID of the parent
  window.
  It is possible to use the Desktop as parent, but this may cause
  problems (message box displayed in the wrong position, with incorrect
  focus, or who know)

* Is it possible to modify bdist_wininst (in a future release) so that,
  when executing the post install script, the name of the project being
  installed is passed in argv[2]?

  This change does not break existing code.



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

iEYEARECAAYFAkyMyUsACgkQscQJ24LbaUTAKACfQJDRgrPqkTo+IhTXTZ/zQyop
7Z0AniXpSCvyGpADk87Ybmu1RT0noBO1
=kSwm
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Sun Sep 12 18:08:54 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 12 Sep 2010 18:08:54 +0200
Subject: [Distutils] bdist_wininst and dependencies with setuptools
In-Reply-To: <4C8A155C.1070608@gmail.com>
References: <4C891B58.8010403@gmail.com>	<20100909210309.A307C3A4069@sparrow.telecommunity.com>	<4C89559C.7080905@gmail.com>	<20100910021331.09C373A4069@sparrow.telecommunity.com>
	<4C8A155C.1070608@gmail.com>
Message-ID: <4C8CFB16.5040007@v.loewis.de>

> By the way, is it possible, from the postinstall script, to know the
> Python instance used?

Sure: the python interpreter running the postinstall script *is* the
one being used. Look at sys.executable.

> There is one thing I'm not sure to understand about the bdist_wininst
> and bdist_msi commands: what is the reason why they don't simply execute
> `python setup.py install` in the background?

Primarily because this would users require to have Visual Studio
installed, plus potentially tons of header files and other build
dependencies (e.g. setuptools). Other reasons are:
- with a plain "setup.py install", uninstallation is not supported,
  but that is a feature of both bdist_wininst and bdist_msi
- you need to unpack the files first to run "setup.py install":
  where would you unpack them to?
- it's more efficient: installation runs faster.

Regards,
Martin

From pje at telecommunity.com  Sun Sep 12 20:08:45 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 12 Sep 2010 14:08:45 -0400
Subject: [Distutils] please fix easy_install shorter URL preference
 (Was: easy_install wrong download site preference)
In-Reply-To: <AANLkTi=LJ-JrfXTmZzpuCjxnmY=SZH1bhbNTnkEXMpCW@mail.gmail.c
 om>
References: <AANLkTi=LJ-JrfXTmZzpuCjxnmY=SZH1bhbNTnkEXMpCW@mail.gmail.com>
Message-ID: <20100912180857.370603A40F5@sparrow.telecommunity.com>

At 12:08 PM 9/12/2010 +0300, anatoly techtonik wrote:

>https://sourceforge.net/apps/trac/halfcooked/ticket/29
>
>Gerald is the second package from the last 4 months that I couldn't
>install due to this very obscure behavior, and I suspect there are
>more.

Gerald installs fine when I try it, and from the same URL (which 
isn't the shortest in any case).  I suspect you are not using the 
current version of easy_install, as the problem shown is due to 
Sourceforge's use of '/download' URLs.

That issue was fixed in October 2009, so you are likely using 
something <0.6c11.

(Or perhaps you are using distribute, which has still not applied 
this bug fix almost a year later.)


>Phillip, could you, please, still run through your archives to success
>in explaining why this logic of choosing a shorter download URL is
>necessary? I'd really to see what packages benefit from it,

It was originally added for PIL and other effbot-released packages; 
it's retained because to change it now would introduce random 
breakages to other projects, in order to benefit one whose source 
filenames are ambiguous anyway.


>I believe Google protocol buffers popularity alone is enough to change
>the behavior.

Right now, the naming of the two source distributions is ambiguous, 
even for humans.

Note, however, that since the full source distribution *also* 
includes the python code, all that's needed is to change its setup.py 
slightly and move it to the root of the source tree.

(The changes needed would consist of adding 
'package_dir={"":"python"}' to the setup() options, and changing 
relative path uses in the setup.py so that they don't assume the 
current directory is the 'python' subtree...  i.e., mainly just 
changing all '../src' occurrences to 'src'.)

In the alternative, calling the release that contains all languages 
'protobuf-all-2.3.0.*' rather than 'protobuf' would also fix the issue.



From pje at telecommunity.com  Sun Sep 12 20:22:07 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 12 Sep 2010 14:22:07 -0400
Subject: [Distutils] [ANN] setuptools post install script for
 bdist_wininst
In-Reply-To: <4C8CC94B.4000806@gmail.com>
References: <4C8B9560.9000702@gmail.com>
	<20100911181015.08BE23A4069@sparrow.telecommunity.com>
	<4C8BDD29.5030505@gmail.com>
	<20100911212230.68E693A4069@sparrow.telecommunity.com>
	<4C8CC94B.4000806@gmail.com>
Message-ID: <20100912182208.439CA3A40F5@sparrow.telecommunity.com>

At 02:36 PM 9/12/2010 +0200, Manlio Perillo wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Il 11/09/2010 23:22, P.J. Eby ha scritto:
> > At 09:48 PM 9/11/2010 +0200, Manlio Perillo wrote:
> >> Is it possible to put required DLLs inside an egg?
> >
> > Yes, but they have to be adjacent to any Python extensions (.pyd's) that
> > use them.
> >
>
>Good to know, thanks.
>
>But how can I create such a egg?

In the same way that you'd create a distutils-based package that 
installs shared libraries next to Python extensions.  (i.e., not easily.)

>And if this is possible, what do you think is the reasons why packages
>like pyqt do not release such eggs?

Because major C extensions (e.g. wx, numpy, pywin32) tend to have 
special build requirements for their libraries that aren't handled 
well by the distutils, or the build process predated the distutils, 
or the build process wasn't originally designed to be used with 
Python, etc. etc.


>It should not be hard to track installed dependencies, as an example
>using the --record option of easy_install, and then registering all
>installed files (and directories) with `file_created` and
>`directory_created` functions.
>
>The only problem is that created directories are not reported in the
>record, but if files are always listed ordered, it should not be a problem.

That's not the only problem: if you install A, then B, and both 
depend on C, then if you uninstall A you will break B.  You would 
have to also track shared use of dependencies.

This situation is a big mess, and I haven't needed it for myself or 
any client as yet, so I've avoided the whole subject.


>Some other related questions:
>
>* Do you think you can change ez_setup.py so that the code used to
>   check if setuptools must be installed is available as a separate
>   function?

Grab the bit that looks like this:

try:
    import pkg_resources
except ImportError:
    # it's not installed
else:
     try:
         pkg_resources.require('setuptools>='+version)
     except pkg_resources.VersionConflict, e:
         # older version is installed
     except pkg_resources.DistributionNotFound:
         # it's not installed
     else:
         # it's installed

Season to taste.  ;-)


>   For normal package dependencies (and assuming setuptools is
>   available) I can just use working_set.__contains__(dist)

No, you need to use require() or resolve() or some other API that:

1. Checks versions, and
2. Handles recursive dependencies


>* Is it safe to call `ez_setup.use_setuptools` setting `to_dir`
>   parameter to `sysconfig.get_python_lib()`?

It's safe for setuptools, but whether it's safe in the context of a 
bdist_wininst I'm not sure.


>   By default the setuptools egg is copied to the same directory where
>   the bdist_wininst file is, and this is not safe since the user may
>   delete these files.

You could also fix that by calling easy_install(['--always-copy', 
'setuptools']), in the case where you've had to install setuptools.


>* Is it possible to get the ID of the main window of the bdist_wininst
>   application?
>   I need it because MessageBox function requires the ID of the parent
>   window.
>   It is possible to use the Desktop as parent, but this may cause
>   problems (message box displayed in the wrong position, with incorrect
>   focus, or who know)
>
>* Is it possible to modify bdist_wininst (in a future release) so that,
>   when executing the post install script, the name of the project being
>   installed is passed in argv[2]?
>
>   This change does not break existing code.

I don't know the answers to these questions.


From manlio.perillo at gmail.com  Mon Sep 13 14:03:04 2010
From: manlio.perillo at gmail.com (Manlio Perillo)
Date: Mon, 13 Sep 2010 14:03:04 +0200
Subject: [Distutils] [ANN] setuptools post install script for
	bdist_wininst
In-Reply-To: <20100912182208.439CA3A40F5@sparrow.telecommunity.com>
References: <4C8B9560.9000702@gmail.com>
	<20100911181015.08BE23A4069@sparrow.telecommunity.com>
	<4C8BDD29.5030505@gmail.com>
	<20100911212230.68E693A4069@sparrow.telecommunity.com>
	<4C8CC94B.4000806@gmail.com>
	<20100912182208.439CA3A40F5@sparrow.telecommunity.com>
Message-ID: <4C8E12F8.3040104@gmail.com>

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

Il 12/09/2010 20:22, P.J. Eby ha scritto:
> At 02:36 PM 9/12/2010 +0200, Manlio Perillo wrote:
> [...]
> 
>> It should not be hard to track installed dependencies, as an example
>> using the --record option of easy_install, and then registering all
>> installed files (and directories) with `file_created` and
>> `directory_created` functions.
>>
>> The only problem is that created directories are not reported in the
>> record, but if files are always listed ordered, it should not be a
>> problem.
> 
> That's not the only problem: if you install A, then B, and both depend
> on C, then if you uninstall A you will break B.  You would have to also
> track shared use of dependencies.
> 
> This situation is a big mess, and I haven't needed it for myself or any
> client as yet, so I've avoided the whole subject.
> 

The simplest solutions are:
* use py2exe or pyinstaller

  The problem is that there are some issues using them:
    - my scripts are handled by setuptools, and I use pkg_resource
      plugins and project data; this seems to not be supported
    - python >= 2.6 support have several issues

* use virtualenv, and let the unistaller simply wipe out the virtual
  enviromnent

  The problem is that this requires a custom installer.

> 
>> Some other related questions:
>>
>> * Do you think you can change ez_setup.py so that the code used to
>>   check if setuptools must be installed is available as a separate
>>   function?
> 
> Grab the bit that looks like this:
> 

> [...]

Thanks.

> 
> 
>>   For normal package dependencies (and assuming setuptools is
>>   available) I can just use working_set.__contains__(dist)
> 
> No, you need to use require() or resolve() or some other API that:
> 
> 1. Checks versions, and
> 2. Handles recursive dependencies
> 

Right, thanks.


> 
>> * Is it safe to call `ez_setup.use_setuptools` setting `to_dir`
>>   parameter to `sysconfig.get_python_lib()`?
> 
> It's safe for setuptools, but whether it's safe in the context of a
> bdist_wininst I'm not sure.
> 
> 
>>   By default the setuptools egg is copied to the same directory where
>>   the bdist_wininst file is, and this is not safe since the user may
>>   delete these files.
> 
> You could also fix that by calling easy_install(['--always-copy',
> 'setuptools']), in the case where you've had to install setuptools.
> 

This is what I'm doing now.

> [...]



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

iEYEARECAAYFAkyOEvgACgkQscQJ24LbaUTNQwCfcePklerVIA9+cZwqCXCsVJkL
wioAn2m2Yv+nMJZsBLGcX2jrTX5s6w+e
=u0aO
-----END PGP SIGNATURE-----

From setuptools at bugs.python.org  Mon Sep 13 15:33:38 2010
From: setuptools at bugs.python.org (Will)
Date: Mon, 13 Sep 2010 13:33:38 +0000
Subject: [Distutils] [issue115] setup.py = Invalid Syntax
In-Reply-To: <1284384818.79.0.234637305434.issue115@psf.upfronthosting.co.za>
Message-ID: <1284384818.79.0.234637305434.issue115@psf.upfronthosting.co.za>


New submission from Will <william.full.moon at gmail.com>:

I installed Python v3.1.2.

I brought Easy_install via the instructions using CURL and setup.py.

When I wanted to use easy_install to get pySQLite ...

  ** c:\bin\python\v3\scripts\easy_install.exe  -v pysqlite

The install fails.  With a syntax error.  One diagnostic asked for Sphinx.  So I instituted the Sphinx down load.  With the same result (see attached log and error file).

There seems to be a fundamental problem in the Easy_install script, viz:

  File "c:\bin\python\v3\lib\site-packages\distribute-0.6.14-py3.1.egg \setuptools\sandbox.py", line 32, in <lambda>
    ).read(), "setup.py", 'exec'),
  File "setup.py", line 80
    print "Is sphinx installed? If not, try 'sudo easy_install sphinx'."
                                                                       ^
I've tried to capture the error and stdout in the attached log file.

Cheers,
          Will

----------
files: sqlite.log
messages: 546
nosy: aplatypus
priority: critical
status: unread
title: setup.py = Invalid Syntax
Added file: http://bugs.python.org/setuptools/file71/sqlite.log

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue115>
_______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sqlite.log
Type: application/octet-stream
Size: 15543 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100913/659491d1/attachment-0001.obj>

From pje at telecommunity.com  Mon Sep 13 17:43:56 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 13 Sep 2010 11:43:56 -0400
Subject: [Distutils] [ANN] setuptools post install script for
 bdist_wininst
In-Reply-To: <4C8E12F8.3040104@gmail.com>
References: <4C8B9560.9000702@gmail.com>
	<20100911181015.08BE23A4069@sparrow.telecommunity.com>
	<4C8BDD29.5030505@gmail.com>
	<20100911212230.68E693A4069@sparrow.telecommunity.com>
	<4C8CC94B.4000806@gmail.com>
	<20100912182208.439CA3A40F5@sparrow.telecommunity.com>
	<4C8E12F8.3040104@gmail.com>
Message-ID: <20100913154351.B08A13A403D@sparrow.telecommunity.com>

At 02:03 PM 9/13/2010 +0200, Manlio Perillo wrote:
>The simplest solutions are:
>* use py2exe or pyinstaller
>
>   The problem is that there are some issues using them:
>     - my scripts are handled by setuptools, and I use pkg_resource
>       plugins and project data; this seems to not be supported

I'm not sure what you mean.  If your scripts import pkg_resources, it 
should be included in the resulting .exe or distribution.


>     - python >= 2.6 support have several issues

Is that just a general issue with py2exe/pyinstaller, or is there 
something specific to setuptools?


From manlio.perillo at gmail.com  Mon Sep 13 22:56:37 2010
From: manlio.perillo at gmail.com (Manlio Perillo)
Date: Mon, 13 Sep 2010 22:56:37 +0200
Subject: [Distutils] [ANN] setuptools post install script for
	bdist_wininst
In-Reply-To: <20100913154351.B08A13A403D@sparrow.telecommunity.com>
References: <4C8B9560.9000702@gmail.com>
	<20100911181015.08BE23A4069@sparrow.telecommunity.com>
	<4C8BDD29.5030505@gmail.com>
	<20100911212230.68E693A4069@sparrow.telecommunity.com>
	<4C8CC94B.4000806@gmail.com>
	<20100912182208.439CA3A40F5@sparrow.telecommunity.com>
	<4C8E12F8.3040104@gmail.com>
	<20100913154351.B08A13A403D@sparrow.telecommunity.com>
Message-ID: <4C8E9005.3020203@gmail.com>

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

Il 13/09/2010 17:43, P.J. Eby ha scritto:
> At 02:03 PM 9/13/2010 +0200, Manlio Perillo wrote:
>> The simplest solutions are:
>> * use py2exe or pyinstaller
>>
>>   The problem is that there are some issues using them:
>>     - my scripts are handled by setuptools, and I use pkg_resource
>>       plugins and project data; this seems to not be supported
> 
> I'm not sure what you mean.  

That my scripts are declared using gui_scripts entry points.
Moreover my application make use of entry point based plugins.

> If your scripts import pkg_resources, it
> should be included in the resulting .exe or distribution.
> 
> 
>>     - python >= 2.6 support have several issues
> 
> Is that just a general issue with py2exe/pyinstaller, or is there
> something specific to setuptools?
> 

pyinstaller specific:
http://www.pyinstaller.org/wiki/Python26Win

and (about setuptools support)
http://www.pyinstaller.org/wiki/FAQ#Misc



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

iEYEARECAAYFAkyOkAUACgkQscQJ24LbaUQCPACfV5HiHlf9ruGVLiTciKG0BJvu
WdMAn3xcbiIaQ9GLZYUGU/d048SkBTXa
=Rb+8
-----END PGP SIGNATURE-----

From Ronny.Pfannschmidt at gmx.de  Tue Sep 14 20:53:25 2010
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Tue, 14 Sep 2010 20:53:25 +0200
Subject: [Distutils] whats the best way to depend on tools needed for
 setup.py/setup metadata
Message-ID: <1284490405.24094.5.camel@Klappe2>

Hi,

i'd like to support turning my guess version from hg metadata tool into
a setup dependency and thus kill the need to ship a python file.

Currently i just import it + call a function,
but that doesn't exactly work if the module is missing and a dependency.

Is there any way to turn it into some sort of plugin/extension that
automatically gets installed/used to get that metadata.

regards Ronny




From pje at telecommunity.com  Tue Sep 14 22:00:45 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 14 Sep 2010 16:00:45 -0400
Subject: [Distutils] whats the best way to depend on tools needed for
 setup.py/setup metadata
In-Reply-To: <1284490405.24094.5.camel@Klappe2>
References: <1284490405.24094.5.camel@Klappe2>
Message-ID: <20100914200042.4B0C83A4100@sparrow.telecommunity.com>

At 08:53 PM 9/14/2010 +0200, Ronny Pfannschmidt wrote:
>Hi,
>
>i'd like to support turning my guess version from hg metadata tool into
>a setup dependency and thus kill the need to ship a python file.
>
>Currently i just import it + call a function,
>but that doesn't exactly work if the module is missing and a dependency.
>
>Is there any way to turn it into some sort of plugin/extension that
>automatically gets installed/used to get that metadata.

See my answer here:

http://mail.python.org/pipermail/distutils-sig/2010-August/016690.html

And Jason's follow-up here:

http://mail.python.org/pipermail/distutils-sig/2010-August/016694.html

You may also want to take a look at what hgtools is doing, to get the 
exact code.


From chris at simplistix.co.uk  Tue Sep 14 23:12:30 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 14 Sep 2010 22:12:30 +0100
Subject: [Distutils] virtualenv 1.5 error on windows
Message-ID: <4C8FE53E.1020904@simplistix.co.uk>

Hi All,

   File "virtualenv-1.5\virtualenv.py", line 1645, in <module>
     main()
   File "virtualenv-1.5\virtualenv.py", line 556, in main
     prompt=options.prompt)
   File "virtualenv-1.5\virtualenv.py", line 645, in create_environment
     site_packages=site_packages, clear=clear))
   File "virtualenv-1.5\virtualenv.py", line 769, in install_python
     copy_required_modules(home_dir)
   File "virtualenv-1.5\virtualenv.py", line 723, in copy_required_modules
     dst_filename = change_prefix(filename, dst_prefix)
   File "virtualenv-1.5\virtualenv.py", line 704, in change_prefix
     assert relpath[0] == '/'
AssertionError

Looks like a classic non-cross-platform piece of code, right?

Chris

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

From chris at simplistix.co.uk  Tue Sep 14 23:18:10 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 14 Sep 2010 22:18:10 +0100
Subject: [Distutils] virtualenv 1.4.9 error on windows
In-Reply-To: <4C8FE53E.1020904@simplistix.co.uk>
References: <4C8FE53E.1020904@simplistix.co.uk>
Message-ID: <4C8FE692.5060504@simplistix.co.uk>

1.4.9 blows up differently:

Traceback (most recent call last):
   File "virtualenv-1.4.9\virtualenv.py", line 1489, in <module>
     main()
   File "virtualenv-1.4.9\virtualenv.py", line 526, in main
     use_distribute=options.use_distribute)
   File "virtualenv-1.4.9\virtualenv.py", line 616, in create_environment
     install_setuptools(py_executable, unzip=unzip_setuptools)
   File "virtualenv-1.4.9\virtualenv.py", line 361, in install_setuptools
     _install_req(py_executable, unzip)
   File "virtualenv-1.4.9\virtualenv.py", line 337, in _install_req
     cwd=cwd)
   File "virtualenv-1.4.9\virtualenv.py", line 587, in call_subprocess
     % (cmd_desc, proc.returncode))
OSError: Command C:\virtualenvs\test\Scripts\python.exe -c "#!python
\"\"\"Bootstrap setuptoo...

I had to go back to 1.3.4 to get a workinging virtualenv :-(

Chris

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

From sridharr at activestate.com  Wed Sep 15 06:14:22 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Tue, 14 Sep 2010 21:14:22 -0700
Subject: [Distutils] virtualenv 1.5 error on windows
In-Reply-To: <4C8FE53E.1020904@simplistix.co.uk>
References: <4C8FE53E.1020904@simplistix.co.uk>
Message-ID: <4C90481E.5080703@activestate.com>

  See 
http://bitbucket.org/ianb/virtualenv/issue/60/win-assertionerror-in-change_prefix

1.5 is basically broken on Windows, and it breaks all packages that rely 
on virtualenv ... such as tox. We need a new release.

As for the error you see with 1.4.9, see 
http://bitbucket.org/ianb/virtualenv/issue/11/windows-issue

-srid

On 9/14/2010 2:12 PM, Chris Withers wrote:
> Hi All,
>
>   File "virtualenv-1.5\virtualenv.py", line 1645, in <module>
>     main()
>   File "virtualenv-1.5\virtualenv.py", line 556, in main
>     prompt=options.prompt)
>   File "virtualenv-1.5\virtualenv.py", line 645, in create_environment
>     site_packages=site_packages, clear=clear))
>   File "virtualenv-1.5\virtualenv.py", line 769, in install_python
>     copy_required_modules(home_dir)
>   File "virtualenv-1.5\virtualenv.py", line 723, in copy_required_modules
>     dst_filename = change_prefix(filename, dst_prefix)
>   File "virtualenv-1.5\virtualenv.py", line 704, in change_prefix
>     assert relpath[0] == '/'
> AssertionError
>
> Looks like a classic non-cross-platform piece of code, right?
>
> Chris
>


From chris at simplistix.co.uk  Wed Sep 15 15:53:30 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 15 Sep 2010 14:53:30 +0100
Subject: [Distutils] distribution name capitalisation considered important ;
	-)
Message-ID: <4C90CFDA.5030903@simplistix.co.uk>

Hi All,

Looks like we have quite a consistent set of rules with regard to 
captilisation of package names on file systems where case isn't 
important, shame the same can't be said for distribution names.

So, looks like case is important in package names.

With distribution names, it becomes much more murky. Setuptools, and so 
all the ilk that use it, is happy to ignore case naming for 
distributions. To make matters worse, it also uses os.path.normcase on 
any distributions obtained from a Windows file system, which will 
*always* corrupt any distribution names that aren't all lower case already.

These differences cause subtle problems in tools which attempt to pin 
versions of particular distributions.

So, I guess I'm asking why we don't just say "distribution names are 
case sensitive" and be done with it? If the case of a requirement or 
distribution name is wrong, it would be good to get early failures 
rather than subtle and annoying bugs later on down the line.

Of course, the horse is already bolted on this. The only "sane" option 
now would be for all distribution names to be lowercased by all tools 
all of the time. How do others feel about this?

Chris


From eric at trueblade.com  Wed Sep 15 16:31:50 2010
From: eric at trueblade.com (Eric Smith)
Date: Wed, 15 Sep 2010 10:31:50 -0400
Subject: [Distutils] distribution name capitalisation considered
 important ; -)
In-Reply-To: <4C90CFDA.5030903@simplistix.co.uk>
References: <4C90CFDA.5030903@simplistix.co.uk>
Message-ID: <4C90D8D6.5040601@trueblade.com>

On 9/15/2010 9:53 AM, Chris Withers wrote:
> Of course, the horse is already bolted on this. The only "sane" option
> now would be for all distribution names to be lowercased by all tools
> all of the time. How do others feel about this?

I have been bitten by this recently, with pinning versions via buildout. 
I agree it would be nice to make everything case sensitive, but I also 
agree that's not practical. I think lowercasing is reasonable.

Eric.

From sridharr at activestate.com  Wed Sep 15 17:57:01 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 15 Sep 2010 08:57:01 -0700
Subject: [Distutils] distribution name capitalisation considered
 important ; -)
In-Reply-To: <4C90CFDA.5030903@simplistix.co.uk>
References: <4C90CFDA.5030903@simplistix.co.uk>
Message-ID: <4C90ECCD.4080807@activestate.com>

  On 9/15/2010 6:53 AM, Chris Withers wrote:
> Looks like we have quite a consistent set of rules with regard to 
> captilisation of package names on file systems where case isn't 
> important, shame the same can't be said for distribution names. 
> [...]These differences cause subtle problems in tools which attempt to 
> pin versions of particular distributions. 
Going by what you wrote about pinning versions, are you talking about 
Buildout?
> The only "sane" option now would be for all distribution names to be 
> lowercased by all tools all of the time. How do others feel about this? 
pip, easy_install and pypm already ignore case. But not buildout? I 
suggest that we a) make pypi disallow registering package names with a 
differing case b) make buildout case-insensitive.

-srid

From chris at simplistix.co.uk  Wed Sep 15 17:59:36 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 15 Sep 2010 16:59:36 +0100
Subject: [Distutils] distribution name capitalisation considered
 important ; -)
In-Reply-To: <4C90ECCD.4080807@activestate.com>
References: <4C90CFDA.5030903@simplistix.co.uk>
	<4C90ECCD.4080807@activestate.com>
Message-ID: <4C90ED68.3050902@simplistix.co.uk>

On 15/09/2010 16:57, Sridhar Ratnakumar wrote:
> On 9/15/2010 6:53 AM, Chris Withers wrote:
>> Looks like we have quite a consistent set of rules with regard to
>> captilisation of package names on file systems where case isn't
>> important, shame the same can't be said for distribution names.
>> [...]These differences cause subtle problems in tools which attempt to
>> pin versions of particular distributions.
> Going by what you wrote about pinning versions, are you talking about
> Buildout?

Yes, but I expect the subtleties apply to otehr tools too...

>> The only "sane" option now would be for all distribution names to be
>> lowercased by all tools all of the time. How do others feel about this?
> pip, easy_install and pypm already ignore case.

...sometimes ;-)

> But not buildout? I
> suggest that we a) make pypi disallow registering package names with a
> differing case

That won't help, and it's not feasible. PyPI is far from the only index 
people use.

> b) make buildout case-insensitive.

Indeed.

Chris

From sridharr at activestate.com  Wed Sep 15 18:37:20 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Wed, 15 Sep 2010 09:37:20 -0700
Subject: [Distutils] distribution name capitalisation considered
 important ; -)
In-Reply-To: <4C90ED68.3050902@simplistix.co.uk>
References: <4C90CFDA.5030903@simplistix.co.uk>
	<4C90ECCD.4080807@activestate.com>
	<4C90ED68.3050902@simplistix.co.uk>
Message-ID: <4C90F640.5030903@activestate.com>

  On 9/15/2010 8:59 AM, Chris Withers wrote:
> On 15/09/2010 16:57, Sridhar Ratnakumar wrote:
>> On 9/15/2010 6:53 AM, Chris Withers wrote:
>>> Looks like we have quite a consistent set of rules with regard to
>>> captilisation of package names on file systems where case isn't
>>> important, shame the same can't be said for distribution names.
>>> [...]These differences cause subtle problems in tools which attempt to
>>> pin versions of particular distributions.
>> Going by what you wrote about pinning versions, are you talking about
>> Buildout?
> Yes, but I expect the subtleties apply to otehr tools too...
Hmm. I wonder if distutils2' metadata parser and distribution classes 
(will) handle names case-insensitively.
>>> lowercased by all tools all of the time. How do others feel about this?
>> pip, easy_install and pypm already ignore case.
> The only "sane" option now would be for all distribution names to be
>
> ...sometimes ;-)
pypm always ignores case, I am not sure about pip, easy_install. 
"pip|easy_install install pastescript" worked for me though.
>> But not buildout? I
>> suggest that we a) make pypi disallow registering package names with a
>> differing case
> That won't help, and it's not feasible. PyPI is far from the only 
> index people use.
Are there package indexes, apart from PyPI, that allows registering 
packages?
> b) make buildout case-insensitive.
> Indeed. 
Doing so is a good idea. It didn't lead to any conflicts at least in my 
experience. Maybe make this part of the metadata parser in distutils2, 
Tarek?

-srid

From pje at telecommunity.com  Wed Sep 15 20:58:21 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 15 Sep 2010 14:58:21 -0400
Subject: [Distutils] distribution name capitalisation considered
 important ; -)
In-Reply-To: <4C90ED68.3050902@simplistix.co.uk>
References: <4C90CFDA.5030903@simplistix.co.uk>
	<4C90ECCD.4080807@activestate.com>
	<4C90ED68.3050902@simplistix.co.uk>
Message-ID: <20100915185831.0FD473A403D@sparrow.telecommunity.com>

At 04:59 PM 9/15/2010 +0100, Chris Withers wrote:
>On 15/09/2010 16:57, Sridhar Ratnakumar wrote:
>>On 9/15/2010 6:53 AM, Chris Withers wrote:
>>>Looks like we have quite a consistent set of rules with regard to
>>>captilisation of package names on file systems where case isn't
>>>important, shame the same can't be said for distribution names.
>>>[...]These differences cause subtle problems in tools which attempt to
>>>pin versions of particular distributions.
>>Going by what you wrote about pinning versions, are you talking about
>>Buildout?
>
>Yes, but I expect the subtleties apply to otehr tools too...
>
>>>The only "sane" option now would be for all distribution names to be
>>>lowercased by all tools all of the time. How do others feel about this?
>>pip, easy_install and pypm already ignore case.
>
>...sometimes ;-)

I can't speak to the others, but setuptools *always* ignores 
case.  If you have found it not to, please file a bug report so I can fix it.


From martin at v.loewis.de  Thu Sep 16 13:49:15 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 16 Sep 2010 13:49:15 +0200
Subject: [Distutils] distribution name capitalisation considered
 important ; -)
In-Reply-To: <4C90ECCD.4080807@activestate.com>
References: <4C90CFDA.5030903@simplistix.co.uk>
	<4C90ECCD.4080807@activestate.com>
Message-ID: <4C92043B.6040303@v.loewis.de>

> a) make pypi disallow registering package names with a
> differing case

That is already the case.

Regards,
Martin

From jim at zope.com  Fri Sep 17 17:31:54 2010
From: jim at zope.com (Jim Fulton)
Date: Fri, 17 Sep 2010 11:31:54 -0400
Subject: [Distutils] distribution name capitalisation considered
 important ; -)
In-Reply-To: <4C90CFDA.5030903@simplistix.co.uk>
References: <4C90CFDA.5030903@simplistix.co.uk>
Message-ID: <AANLkTi=xs9=_WY--cY4QsL01HiugyQLhu9SV9Ef2MLO_@mail.gmail.com>

On Wed, Sep 15, 2010 at 9:53 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> Hi All,
>
> Looks like we have quite a consistent set of rules with regard to
> captilisation of package names on file systems where case isn't important,
> shame the same can't be said for distribution names.
>
> So, looks like case is important in package names.
>
> With distribution names, it becomes much more murky. Setuptools, and so all
> the ilk that use it, is happy to ignore case naming for distributions. To
> make matters worse, it also uses os.path.normcase on any distributions
> obtained from a Windows file system, which will *always* corrupt any
> distribution names that aren't all lower case already.
>
> These differences cause subtle problems in tools which attempt to pin
> versions of particular distributions.

I've pretty much decided to view these problems in buildout as bugs.

> So, I guess I'm asking why we don't just say "distribution names are case
> sensitive" and be done with it? If the case of a requirement or distribution
> name is wrong, it would be good to get early failures rather than subtle and
> annoying bugs later on down the line.
>
> Of course, the horse is already bolted on this.

Yup. Sadly.

> The only "sane" option now
> would be for all distribution names to be lowercased by all tools all of the
> time. How do others feel about this?

Regardless of how this is accomplished internally, I agree that software
(like buildout) that deals with project specifications needs to assume that
project names are case insensitive.

Jim

-- 
Jim Fulton

From techtonik at gmail.com  Sat Sep 18 18:59:46 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 18 Sep 2010 19:59:46 +0300
Subject: [Distutils] please fix easy_install shorter URL preference
 (Was: easy_install wrong download site preference)
In-Reply-To: <20100912180857.370603A40F5@sparrow.telecommunity.com>
References: <AANLkTi=LJ-JrfXTmZzpuCjxnmY=SZH1bhbNTnkEXMpCW@mail.gmail.com>
	<20100912180857.370603A40F5@sparrow.telecommunity.com>
Message-ID: <AANLkTi=QtRk_JK6_UOv5OE7B2vM2+v8oXtFkxZ270Q=u@mail.gmail.com>

On Sun, Sep 12, 2010 at 9:08 PM, P.J. Eby <pje at telecommunity.com> wrote:
>
>> https://sourceforge.net/apps/trac/halfcooked/ticket/29
>>
>> Gerald is the second package from the last 4 months that I couldn't
>> install due to this very obscure behavior, and I suspect there are
>> more.
>
> Gerald installs fine when I try it, and from the same URL (which isn't the
> shortest in any case). ?I suspect you are not using the current version of
> easy_install, as the problem shown is due to Sourceforge's use of
> '/download' URLs.

It still fails for me and I can explain why. Fail log is attached.

The SourceForge URL is longer than the same .egg URL for PyPI package.
That's why setuptools choses SF instead of PyPI. But because SF URL
doesn't end with .egg setuptools fails to install it. Seems like
setuptools is crawled with roaches. =)

> That issue was fixed in October 2009, so you are likely using something
> <0.6c11.

I am using setuptools-0.6c11-py2.6.egg on Windows Vista.

> (Or perhaps you are using distribute, which has still not applied this bug
> fix almost a year later.)

Oh no. I am not one of those heretics. =)

>> Phillip, could you, please, still run through your archives to success
>> in explaining why this logic of choosing a shorter download URL is
>> necessary? I'd really to see what packages benefit from it,
>
> It was originally added for PIL and other effbot-released packages; it's
> retained because to change it now would introduce random breakages to other
> projects, in order to benefit one whose source filenames are ambiguous
> anyway.

This argument is a little bit misleading. Do you really think that
PyPI preference over remote site for the same package version will
break anything?

>> I believe Google protocol buffers popularity alone is enough to change
>> the behavior.
>
> Right now, the naming of the two source distributions is ambiguous, even for
> humans.

"even" is not the right word here. For humans there is a lot of
context information that allow them to choose correct download.
Unfortunately, packaging tools are not that smart even if pretend to
be so.

> Note, however, that since the full source distribution *also* includes the
> python code, all that's needed is to change its setup.py slightly and move
> it to the root of the source tree.

If the Python was the only code inside - that'd be acceptable, but it
seems like the proper fix lies in setuptools AI code.

Thanks for support.
-- 
anatoly t.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gerald_install.log
Type: application/octet-stream
Size: 10062 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100918/b3c8482a/attachment.obj>

From pje at telecommunity.com  Sun Sep 19 01:04:54 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 18 Sep 2010 19:04:54 -0400
Subject: [Distutils] please fix easy_install shorter URL preference
 (Was: easy_install wrong download site preference)
In-Reply-To: <AANLkTi=QtRk_JK6_UOv5OE7B2vM2+v8oXtFkxZ270Q=u@mail.gmail.c
 om>
References: <AANLkTi=LJ-JrfXTmZzpuCjxnmY=SZH1bhbNTnkEXMpCW@mail.gmail.com>
	<20100912180857.370603A40F5@sparrow.telecommunity.com>
	<AANLkTi=QtRk_JK6_UOv5OE7B2vM2+v8oXtFkxZ270Q=u@mail.gmail.com>
Message-ID: <20100918230510.B07643A403D@sparrow.telecommunity.com>

At 07:59 PM 9/18/2010 +0300, anatoly techtonik wrote:
>On Sun, Sep 12, 2010 at 9:08 PM, P.J. Eby <pje at telecommunity.com> wrote:
> > That issue was fixed in October 2009, so you are likely using something
> > <0.6c11.
>
>I am using setuptools-0.6c11-py2.6.egg on Windows Vista.

Oops.  My bad - this was actually fixed only 7 months ago, in 
February 2010, and it's not in 0.6c11, only the nightly 
snapshots.  To update your installation, run:

     easy_install -U setuptools

This should give you 0.6c12dev-r_something_or_other.  ;-)


> > Note, however, that since the full source distribution *also* includes the
> > python code, all that's needed is to change its setup.py slightly and move
> > it to the root of the source tree.
>
>If the Python was the only code inside - that'd be acceptable, but it
>seems like the proper fix lies in setuptools AI code.

You do realize that asking everybody to update their version of 
setuptools in order to be able to install one particular package is a 
little unrealistic?  I mean, *your* setuptools is at least seven 
months out of date, so even if I changed this, how long would it be 
till your users updated?  ;-)

In truth, I do have an idea that would actually fix this problem in 
the Google case (a change to the way the source is processed after 
extraction), but it will likely be a while before I can implement it, 
and a while further still before everyone has installed the 
update.  (Note that 0.6c5 and 0.6c9 are still very popular versions, 
and 0.6c9 is like *two years* out of date.)


From chris at simplistix.co.uk  Mon Sep 20 10:37:37 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 20 Sep 2010 09:37:37 +0100
Subject: [Distutils] distribution name capitalisation considered
 important ; -)
In-Reply-To: <20100915185831.0FD473A403D@sparrow.telecommunity.com>
References: <4C90CFDA.5030903@simplistix.co.uk>
	<4C90ECCD.4080807@activestate.com>
	<4C90ED68.3050902@simplistix.co.uk>
	<20100915185831.0FD473A403D@sparrow.telecommunity.com>
Message-ID: <4C971D51.5030508@simplistix.co.uk>

On 15/09/2010 19:58, P.J. Eby wrote:
> I can't speak to the others, but setuptools *always* ignores case. If
> you have found it not to, please file a bug report so I can fix it.

Where's the right place to report?

The problem I had was using a file:// to find-links on Windows, whereby 
setuptools ends up causing os.path.normcase to be called on the 
distribution name, lowercasing an otherwise perfectly correctly cased 
distribution name...

Chris

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

From pje at telecommunity.com  Mon Sep 20 23:16:42 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 20 Sep 2010 17:16:42 -0400
Subject: [Distutils] distribution name capitalisation considered
 important ; -)
In-Reply-To: <4C971D51.5030508@simplistix.co.uk>
References: <4C90CFDA.5030903@simplistix.co.uk>
	<4C90ECCD.4080807@activestate.com>
	<4C90ED68.3050902@simplistix.co.uk>
	<20100915185831.0FD473A403D@sparrow.telecommunity.com>
	<4C971D51.5030508@simplistix.co.uk>
Message-ID: <20100920211635.4C23C3A4079@sparrow.telecommunity.com>

At 09:37 AM 9/20/2010 +0100, Chris Withers wrote:
>On 15/09/2010 19:58, P.J. Eby wrote:
>>I can't speak to the others, but setuptools *always* ignores case. If
>>you have found it not to, please file a bug report so I can fix it.
>
>Where's the right place to report?

http://bugs.python.org/setuptools/


>The problem I had was using a file:// to find-links on Windows, 
>whereby setuptools ends up causing os.path.normcase to be called on 
>the distribution name, lowercasing an otherwise perfectly correctly 
>cased distribution name...

...resulting in what problem?


From setuptools at bugs.python.org  Tue Sep 21 05:10:42 2010
From: setuptools at bugs.python.org (Ted Tibbetts)
Date: Tue, 21 Sep 2010 03:10:42 +0000
Subject: [Distutils] [issue116] typo in command.bdist_enc.make_zipfile
In-Reply-To: <1285038642.94.0.0573017627697.issue116@psf.upfronthosting.co.za>
Message-ID: <1285038642.94.0.0573017627697.issue116@psf.upfronthosting.co.za>


New submission from Ted Tibbetts <intuited at gmail.com>:

Looks like there is a typo in the function `make_zipfile` in the file `command/bdist_enc`: the last line of the else clause of the if construct at the end of the function passes `file` as the third parameter to `visit`; it should be passing `files`, I think.

Symptoms include the exception `TypeError("'instancemethod' object is not iterable")` when attempting to run `easy_install -n some_sdist.tar.gz`.

Applying the attached patch seems to resolve the issue; I'm still not entirely sure what it's telling me, but at least it's not spitting out a stack trace.

----------
files: bdist_egg.py.diff
messages: 550
nosy: intuited
priority: bug
status: unread
title: typo in command.bdist_enc.make_zipfile
Added file: http://bugs.python.org/setuptools/file72/bdist_egg.py.diff

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue116>
_______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bdist_egg.py.diff
Type: application/octet-stream
Size: 370 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100921/debb6d9e/attachment.obj>

From techtonik at gmail.com  Tue Sep 21 12:35:25 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 21 Sep 2010 13:35:25 +0300
Subject: [Distutils] docs/ vs doc/
Message-ID: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>

Hi,

I see that distutils2 promotes storing documentation in docs/
directory while Python sources use Doc/
I'd like to see this changed before distutils2 is released beta.

In my projects checkouts there are 80 project that use doc/
directories. Among these are:
- subversion
- hg
- sphinx
- trac
- scons
- twisted

docs/ directory is used by 61 project, the most famous are:
- xalan
- fop
- moinmoin
- cmd2
- googlecl


There are some arguments for 'doc/':
1. there is no plural for 'documentation'
2. bin/ is a common name for storing executables, although there is
plural for 'binary'
3. we still use src/ instead of sources/

Any thoughts/objections?
--
anatoly t.

From fuzzyman at voidspace.org.uk  Tue Sep 21 12:38:50 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 21 Sep 2010 11:38:50 +0100
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
Message-ID: <AANLkTi=Rk-Avv6jMuxHawoRGtg61u7MKCijbASWH4FoW@mail.gmail.com>

I prefer docs. It seems more natural.

Michael

On 21 September 2010 11:35, anatoly techtonik <techtonik at gmail.com> wrote:

> Hi,
>
> I see that distutils2 promotes storing documentation in docs/
> directory while Python sources use Doc/
> I'd like to see this changed before distutils2 is released beta.
>
> In my projects checkouts there are 80 project that use doc/
> directories. Among these are:
> - subversion
> - hg
> - sphinx
> - trac
> - scons
> - twisted
>
> docs/ directory is used by 61 project, the most famous are:
> - xalan
> - fop
> - moinmoin
> - cmd2
> - googlecl
>
>
> There are some arguments for 'doc/':
> 1. there is no plural for 'documentation'
> 2. bin/ is a common name for storing executables, although there is
> plural for 'binary'
> 3. we still use src/ instead of sources/
>
> Any thoughts/objections?
> --
> anatoly t.
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100921/f4ac03f4/attachment.html>

From attilaolah at gmail.com  Tue Sep 21 13:12:31 2010
From: attilaolah at gmail.com (=?UTF-8?B?QXR0aWxhIE9sw6Fo?=)
Date: Tue, 21 Sep 2010 13:12:31 +0200
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTi=Rk-Avv6jMuxHawoRGtg61u7MKCijbASWH4FoW@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<AANLkTi=Rk-Avv6jMuxHawoRGtg61u7MKCijbASWH4FoW@mail.gmail.com>
Message-ID: <AANLkTimG11NXLSh92YwJczX3+S2fOZzo_D-z+VLdAF6T@mail.gmail.com>

On Tue, Sep 21, 2010 at 12:38, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> I prefer docs. It seems more natural.

Me too. I think I got the habit of using "docs" instead of "doc" from
some Zope guys.

http://www.google.com/search?q=site:svn.zope.org+inurl:doc ~600 results
http://www.google.com/search?q=site:svn.zope.org+inurl:docs ~ 13000 results

Attila

From g.brandl at gmx.net  Tue Sep 21 13:34:51 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 21 Sep 2010 13:34:51 +0200
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
Message-ID: <i7a595$291$1@dough.gmane.org>

Am 21.09.2010 12:35, schrieb anatoly techtonik:
> Hi,
> 
> I see that distutils2 promotes storing documentation in docs/
> directory while Python sources use Doc/
> I'd like to see this changed before distutils2 is released beta.
> 
> In my projects checkouts there are 80 project that use doc/
> directories. Among these are:
> - subversion
> - hg
> - sphinx
> - trac
> - scons
> - twisted
> 
> docs/ directory is used by 61 project, the most famous are:
> - xalan
> - fop
> - moinmoin
> - cmd2
> - googlecl
> 
> 
> There are some arguments for 'doc/':
> 1. there is no plural for 'documentation'

FWIW, "docs" is probably short for "the documents".

That said, I have no preference and as long as a solution works with both
doc/ and docs/ it's fine with me.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From ben+python at benfinney.id.au  Tue Sep 21 13:55:32 2010
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 21 Sep 2010 21:55:32 +1000
Subject: [Distutils] docs/ vs doc/
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
Message-ID: <8739t35n0r.fsf@benfinney.id.au>

anatoly techtonik <techtonik at gmail.com> writes:

> There are some arguments for 'doc/':
> 1. there is no plural for 'documentation'
> 2. bin/ is a common name for storing executables, although there is
> plural for 'binary'
> 3. we still use src/ instead of sources/

* ?doc/? is consistent with the standardised directory name on many
  operating systems (those that inspired, or are based on, the FHS)

I don't think a vote is appropriate (I think the choice should be made
on merit, not popularity), but if anyone's counting, I prefer ?doc/?.

-- 
 \      ?Progress might have been all right once, but it's gone on too |
  `\                                                long.? ?Ogden Nash |
_o__)                                                                  |
Ben Finney


From barry at python.org  Tue Sep 21 13:57:15 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 21 Sep 2010 07:57:15 -0400
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
Message-ID: <20100921075715.632933f7@snowdog>

On Sep 21, 2010, at 01:35 PM, anatoly techtonik wrote:

>I see that distutils2 promotes storing documentation in docs/
>directory while Python sources use Doc/
>I'd like to see this changed before distutils2 is released beta.

What does "promotes" mean?  That only docs/ can be used?

>In my projects checkouts there are 80 project that use doc/
>directories. Among these are:
>- subversion
>- hg
>- sphinx
>- trac
>- scons
>- twisted
>
>docs/ directory is used by 61 project, the most famous are:
>- xalan
>- fop
>- moinmoin
>- cmd2
>- googlecl

So, almost evenly split. :)

I'm with Michael, I prefer docs/ and that's what I use for Mailman and all my
libraries.  It just *seems* righter. ;)

I still don't quite know in what way distutils2 promotes docs/ but I do think
both choices need to be easily supported.  Also for unittest2, since my docs/
directories just happen to also contain tests.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100921/27621950/attachment-0001.pgp>

From techtonik at gmail.com  Tue Sep 21 16:20:48 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 21 Sep 2010 17:20:48 +0300
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <20100921075715.632933f7@snowdog>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
Message-ID: <AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>

On Tue, Sep 21, 2010 at 2:57 PM, Barry Warsaw <barry at python.org> wrote:
>
>>I see that distutils2 promotes storing documentation in docs/
>>directory while Python sources use Doc/
>>I'd like to see this changed before distutils2 is released beta.
>
> What does "promotes" mean? ?That only docs/ can be used?

upload_docs command will extract documentation from 'docs/' by
default. I wouldn't bring this question if it could also process
'doc/' in cases where 'docs/' are absent. You can specify upload
directory explicitly, but sometimes you'd really like it to just work.

-- 
anatoly t.

From barry at python.org  Tue Sep 21 16:34:24 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 21 Sep 2010 10:34:24 -0400
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
Message-ID: <20100921103424.745016d4@mission>

On Sep 21, 2010, at 05:20 PM, anatoly techtonik wrote:

>On Tue, Sep 21, 2010 at 2:57 PM, Barry Warsaw <barry at python.org> wrote:
>>
>>>I see that distutils2 promotes storing documentation in docs/
>>>directory while Python sources use Doc/
>>>I'd like to see this changed before distutils2 is released beta.
>>
>> What does "promotes" mean? ?That only docs/ can be used?
>
>upload_docs command will extract documentation from 'docs/' by
>default. I wouldn't bring this question if it could also process
>'doc/' in cases where 'docs/' are absent. You can specify upload
>directory explicitly, but sometimes you'd really like it to just work.

Gotcha, thanks.

Yes it should definitely use doc/ if docs/ is missing.  However, upload_docs
never quite works out of the box for me anyway.  First, it insists on an
index.html file, which my Sphinx builds never seem to write, so I always have
to add a symlink.  Second, it doesn't seem to play nicely with the location
that my buildout-based builds puts the docs, so I always also have to use
--upload-dir.  Yes, it would be nice if both of these problems were fixed too.
Yes, I should report them as bugs (or just fix 'em ;).

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100921/7fe3b77c/attachment.pgp>

From fdrake at acm.org  Tue Sep 21 16:38:20 2010
From: fdrake at acm.org (Fred Drake)
Date: Tue, 21 Sep 2010 10:38:20 -0400
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
Message-ID: <AANLkTinJr2awGhh0MOpBTCAuJ0B6ahzjrTn2SMH+N0=H@mail.gmail.com>

On Tue, Sep 21, 2010 at 10:20 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> upload_docs command will extract documentation from 'docs/' by
> default. I wouldn't bring this question if it could also process
> 'doc/' in cases where 'docs/' are absent. You can specify upload
> directory explicitly, but sometimes you'd really like it to just work.

Of course, we'd have to define what "just work" means here.  I'd be
fine having to always tell upload_docs where to look, provided I can
do that in the setup.cfg d2 uses.

That said, I don't *mind* if it looks for both docs/ and doc/, or even
care which it looks for first.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A storm broke loose in my mind."? --Albert Einstein

From pje at telecommunity.com  Tue Sep 21 17:12:04 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 21 Sep 2010 11:12:04 -0400
Subject: [Distutils] [issue116] typo in  command.bdist_enc.make_zipfile
In-Reply-To: <1285038642.94.0.0573017627697.issue116@psf.upfronthosting. co.za>
References: <1285038642.94.0.0573017627697.issue116@psf.upfronthosting.co.za>
	<1285038642.94.0.0573017627697.issue116@psf.upfronthosting.co.za>
Message-ID: <20100921151157.23AC53A4079@sparrow.telecommunity.com>

At 03:10 AM 9/21/2010 +0000, Ted Tibbetts wrote:
>Looks like there is a typo in the function `make_zipfile` in the 
>file `command/bdist_enc`: the last line of the else clause of the if 
>construct at the end of the function passes `file` as the third 
>parameter to `visit`; it should be passing `files`, I think.
>
>Symptoms include the exception `TypeError("'instancemethod' object 
>is not iterable")` when attempting to run `easy_install -n some_sdist.tar.gz`.
>
>Applying the attached patch seems to resolve the issue; I'm still 
>not entirely sure what it's telling me, but at least it's not 
>spitting out a stack trace.

Hi Ted.  It appears you are using distribute, not 
setuptools.  Unfortunately, some Linux distributions are shipping 
distribute (a fork of setuptools) under the name "setuptools", which 
creates user confusion.  If you are using your Linux distribution's 
installation of setuptools, please make sure to file this bug with 
your Linux distributor as well.

Distribute has many changes relative to setuptools, some of which 
have introduced new bugs.  It looks like this is the specific change 
that introduced the problem you're experiencing:

    http://bitbucket.org/tarek/distribute/changeset/512db2c962e4

In this case the problem is fairly minor, since it only affects dry 
runs that would probably fail later in the process anyway.

Unless you are using Distribute by choice for its additional 
features, you may wish to uninstall it and replace it with a stable 
version of setuptools.  (Unfortunately, if you are using your Linux 
distributor's installation of it, this may not be possible.)


From ziade.tarek at gmail.com  Tue Sep 21 17:39:25 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 21 Sep 2010 17:39:25 +0200
Subject: [Distutils] [issue116] typo in command.bdist_enc.make_zipfile
In-Reply-To: <1285038642.94.0.0573017627697.issue116@psf.upfronthosting.co.za>
References: <1285038642.94.0.0573017627697.issue116@psf.upfronthosting.co.za>
	<1285038642.94.0.0573017627697.issue116@psf.upfronthosting.co.za>
Message-ID: <AANLkTimBFGUQ-0Pu_cqWTrCbyzmavoH1fw79V5xbp3YK@mail.gmail.com>

On Tue, Sep 21, 2010 at 5:10 AM, Ted Tibbetts
<setuptools at bugs.python.org> wrote:
>
> New submission from Ted Tibbetts <intuited at gmail.com>:
..
> Added file: http://bugs.python.org/setuptools/file72/bdist_egg.py.diff

Thanks for the patch, I've applied it. The bug tracker for Distribute
is located at http://bitbucket.org/tarek/distribute/issues.

Regards
Tarek

From setuptools at bugs.python.org  Wed Sep 22 00:10:24 2010
From: setuptools at bugs.python.org (Ted Tibbetts)
Date: Tue, 21 Sep 2010 22:10:24 +0000
Subject: [Distutils] [issue117] Unable to upload package without storing
	password in	~/.pypirc
In-Reply-To: <1285107024.23.0.44730822147.issue117@psf.upfronthosting.co.za>
Message-ID: <1285107024.23.0.44730822147.issue117@psf.upfronthosting.co.za>


New submission from Ted Tibbetts <intuited at gmail.com>:

I can't seem to upload a source distribution without storing my password in ~/.pypirc.

If I have no ~/.pypirc, and I give a the command

    ``$ python setup.py sdist register upload``

and then give my login credentials, this happens at the end:

::

    running register
    Password: 
    Registering terminable_thread to http://pypi.python.org/pypi
    Server response (200): OK
    running upload
    Submitting dist/terminable_thread-0.7.tar.gz to http://pypi.python.org/pypi
    Upload failed (401): Incorrect password

I get similar results if my ``~/.pypirc`` has a line in the ``[pypi]`` section containing just ``password:``, whether or not I omit the ``register`` command.

I was able to upload the distribution by putting my password in ``~/.pypirc``.

The ``upload`` command seems to be checking for the password independently from ``register``; this runs contrary to the documentation_.

.. _documentation: http://docs.python.org/distutils/packageindex.html#pypirc

I'm running the bona fide (not ``distribute``) ``setuptools``, version ``0.6c11``.  This assertion is based on

::

    $ cat `which easy_install` | grep load
    from pkg_resources import load_entry_point
       load_entry_point('setuptools==0.6c11', 'console_scripts', 'easy_install')()

and the fact that I just deleted my old ``setuptools`` and installed by executing the current tarball from the ``setuptools`` PyPI page.

----------
messages: 553
nosy: intuited
priority: bug
status: unread
title: Unable to upload package without storing password in ~/.pypirc

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

From ziade.tarek at gmail.com  Wed Sep 22 00:24:47 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 22 Sep 2010 00:24:47 +0200
Subject: [Distutils] [issue117] Unable to upload package without storing
 password in ~/.pypirc
In-Reply-To: <1285107024.23.0.44730822147.issue117@psf.upfronthosting.co.za>
References: <1285107024.23.0.44730822147.issue117@psf.upfronthosting.co.za>
	<1285107024.23.0.44730822147.issue117@psf.upfronthosting.co.za>
Message-ID: <AANLkTinPm+QD+EzUbvLnWVs7KBc6ZkFsmhcBnV8x4dCi@mail.gmail.com>

This is not related to setuptools but to Distutils so you should file
an issue at bugs.python.org instead.

IIRC I have fixed this in 2.6. What is your Python version ?


On Wed, Sep 22, 2010 at 12:10 AM, Ted Tibbetts
<setuptools at bugs.python.org> wrote:
>
> New submission from Ted Tibbetts <intuited at gmail.com>:
>
> I can't seem to upload a source distribution without storing my password in ~/.pypirc.
>
> If I have no ~/.pypirc, and I give a the command
>
> ? ?``$ python setup.py sdist register upload``
>
> and then give my login credentials, this happens at the end:
>
> ::
>
> ? ?running register
> ? ?Password:
> ? ?Registering terminable_thread to http://pypi.python.org/pypi
> ? ?Server response (200): OK
> ? ?running upload
> ? ?Submitting dist/terminable_thread-0.7.tar.gz to http://pypi.python.org/pypi
> ? ?Upload failed (401): Incorrect password
>
> I get similar results if my ``~/.pypirc`` has a line in the ``[pypi]`` section containing just ``password:``, whether or not I omit the ``register`` command.
>
> I was able to upload the distribution by putting my password in ``~/.pypirc``.
>
> The ``upload`` command seems to be checking for the password independently from ``register``; this runs contrary to the documentation_.
>
> .. _documentation: http://docs.python.org/distutils/packageindex.html#pypirc
>
> I'm running the bona fide (not ``distribute``) ``setuptools``, version ``0.6c11``. ?This assertion is based on
>
> ::
>
> ? ?$ cat `which easy_install` | grep load
> ? ?from pkg_resources import load_entry_point
> ? ? ? load_entry_point('setuptools==0.6c11', 'console_scripts', 'easy_install')()
>
> and the fact that I just deleted my old ``setuptools`` and installed by executing the current tarball from the ``setuptools`` PyPI page.
>
> ----------
> messages: 553
> nosy: intuited
> priority: bug
> status: unread
> title: Unable to upload package without storing password in ~/.pypirc
>
> _______________________________________________
> Setuptools tracker <setuptools at bugs.python.org>
> <http://bugs.python.org/setuptools/issue117>
> _______________________________________________
> _______________________________________________
> 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  Thu Sep 23 10:49:34 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 23 Sep 2010 09:49:34 +0100
Subject: [Distutils] distribution name capitalisation considered
 important ; -)
In-Reply-To: <20100920211635.4C23C3A4079@sparrow.telecommunity.com>
References: <4C90CFDA.5030903@simplistix.co.uk>
	<4C90ECCD.4080807@activestate.com>
	<4C90ED68.3050902@simplistix.co.uk>
	<20100915185831.0FD473A403D@sparrow.telecommunity.com>
	<4C971D51.5030508@simplistix.co.uk>
	<20100920211635.4C23C3A4079@sparrow.telecommunity.com>
Message-ID: <4C9B149E.3010306@simplistix.co.uk>

On 20/09/2010 22:16, P.J. Eby wrote:
>> The problem I had was using a file:// to find-links on Windows,
>> whereby setuptools ends up causing os.path.normcase to be called on
>> the distribution name, lowercasing an otherwise perfectly correctly
>> cased distribution name...
>
> ...resulting in what problem?

...downstream tools, zc.buildout in this case, not functioning properly 
because their version pinning relies on consistent casing.

Yeah, you could say it's a bug in buildout, but really, when the name is 
correct on disk and an intermediary tool decides to screw with the case 
for no good reason, I go with pointing the finger at the tool in the 
middle ;-)

Chris

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

From jaraco at jaraco.com  Thu Sep 23 21:23:25 2010
From: jaraco at jaraco.com (Jason R. Coombs)
Date: Thu, 23 Sep 2010 12:23:25 -0700
Subject: [Distutils] easy_install command arguments not propagated when
 installing source distributions
Message-ID: <12C7AB425F0DD546B6049311F827C74E09785E684B@VA3DIAXVS141.RED001.local>

We're using easy_install 0.6c9 or greater. Our systems are behind a firewall
with a custom cheeseshop. All required packages are available on the
cheeseshop. However, we seem to be unable to install source distributions,
because the dependencies specified in setup_requires aren't resolved with
the parameters (allow-hosts and find-links) passed to easy_install. Here's a
transcript of what happens (with #comments).

(sandbox)jason.coombs at host:~/sandbox$ easy_install -mZ -H
cheeseshop.company.com -f http://cheeseshop.company.com jaraco.compat
Searching for jaraco.compat
Reading http://cheeseshop.company.com
Best match: jaraco.compat 0.1
Downloading http://cheeseshop.company.com/jaraco.compat-0.1.tar.gz
Processing jaraco.compat-0.1.tar.gz
# it found the source distribution, and now runs setup.py from it
Running jaraco.compat-0.1/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-WMIHzo/jaraco.compat-0.1/egg-dist-tmp-XrEJAr
# the source distribution specifies setup_requires="hgtools>=0.4"
Searching for hgtools>=0.4
Reading http://pypi.python.org/simple/hgtools/
# it stalls here for a long time trying to reach a host which is not
accessible due to the firewall
Download error: (110, 'Connection timed out') -- Some packages may not be
found!
Couldn't find index page for 'hgtools' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://pypi.python.org/simple/
# same thing - stalls a long time
Download error: (110, 'Connection timed out') -- Some packages may not be
found!
No local packages or download links found for hgtools>=0.4
Best match: None
Traceback (most recent call last):
# details omitted
AttributeError: 'NoneType' object has no attribute 'clone' # I think this is
the error for "not found" when mercurial is present


I understand the challenge here - setuptools is launching setup.py from the
source distribution for jaraco.compat, and setup.py doesn't accept
parameters for 'allow_hosts' and 'find_links'.

Is there any way that we can use source distributions in this environment
(without customizing each source distribution for the environment)? If not,
perhaps an improvement could be added to setuptools to populate a setup.cfg
file when installing source distributions to include the easy_install flags
supplied to the requiring install.

In other words, the command "easy_install -f http://foo.org -H foo.org
source.package" would

1) Download the source package.
2) Expand it to a temporary directory.
3) Create or customize the setup.cfg for that package (or use --command and
--option) to include dependency_links=['http://foo.org'] and an equivalent
parameter with the same effect as allow_hosts.
4) Run setup.py as above.

I'm not sure all of this is possible or even desirable. I appreciate any
suggestions you may have on this scenario.

I wouldn't be surprised too if someone's already encountered this, but I was
unable to find any resources on it. If that's the case, please accept my
apologies for repeating the question and direct me to the resource or search
terms that will help me locate it.

Much obliged,
Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6448 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100923/00a056ee/attachment.bin>

From pje at telecommunity.com  Thu Sep 23 21:58:51 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 23 Sep 2010 15:58:51 -0400
Subject: [Distutils] easy_install command arguments not propagated when
 installing source distributions
In-Reply-To: <12C7AB425F0DD546B6049311F827C74E09785E684B@VA3DIAXVS141.RE
	D001.local>
References: <12C7AB425F0DD546B6049311F827C74E09785E684B@VA3DIAXVS141.RED001.local>
Message-ID: <20100923195858.132843A4079@sparrow.telecommunity.com>

At 12:23 PM 9/23/2010 -0700, Jason R. Coombs wrote:
>I understand the challenge here - setuptools is launching setup.py from the
>source distribution for jaraco.compat, and setup.py doesn't accept
>parameters for 'allow_hosts' and 'find_links'.

Hm.  This is actually a bit of a hole with respect to 
--allow-hosts.  I'll have to see if there's a way to pass that 
information through (probably not as a setup.cfg file, though).


>Is there any way that we can use source distributions in this environment
>(without customizing each source distribution for the environment)? If not,
>perhaps an improvement could be added to setuptools to populate a setup.cfg
>file when installing source distributions to include the easy_install flags
>supplied to the requiring install.

In the meantime, one quick fix you could implement is to add a 
distutils.cfg to the Lib/distutils/ directory of your Python 
installation(s).  If you want to do this in a (semi-)automated way, you can
run this in any project source directory:

     python setup.py saveopts -g easy_install [options to save]

This will save whatever options you give to the global config file for you.


From chris at simplistix.co.uk  Fri Sep 24 10:25:02 2010
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 24 Sep 2010 09:25:02 +0100
Subject: [Distutils] distribution name capitalisation considered
 important ; -)
In-Reply-To: <AANLkTi=xs9=_WY--cY4QsL01HiugyQLhu9SV9Ef2MLO_@mail.gmail.com>
References: <4C90CFDA.5030903@simplistix.co.uk>
	<AANLkTi=xs9=_WY--cY4QsL01HiugyQLhu9SV9Ef2MLO_@mail.gmail.com>
Message-ID: <4C9C605E.201@simplistix.co.uk>

On 17/09/2010 16:31, Jim Fulton wrote:
>> These differences cause subtle problems in tools which attempt to pin
>> versions of particular distributions.
>
> I've pretty much decided to view these problems in buildout as bugs.

Glad to hear it, in the meantime, buildout-versions works around the 
problem for anyone who hits it...

There's a known issue with buildout-versions and mr.developer, but I 
have a patch, just waiting for tests...

Chris

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

From me at jon-hadley.com  Fri Sep 24 15:45:50 2010
From: me at jon-hadley.com (Jon Hadley)
Date: Fri, 24 Sep 2010 14:45:50 +0100
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too long
Message-ID: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>

I'm trying to install a custom package in a buildout managed Plone 3 site in /develop-src named (for the sake of argument) 'foobar.wontbloodywork'.

Yet I keep getting an error 'z3cform.datetimewidget.pot: File name too long'

I get the same result on a freshly built Ubuntu server with no previous eggs. The custom packages used to install fine in an older (12 month +) project.

It was suggested to me (via the Plone Users mailing list) that this might be a distribute error. Can anyone on this list offer any insights?


Results of buildout -vvvv below:

Develop: '/Users/foobar/development/sites/gpi/gpi3/develop-src/foobar.wontbloodywork' in: '/Users/foobar/development/sites/gpi/gpi3/develop-src/foobar.wontbloodywork'
/var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/tmpXFTFnd -q develop -mxN -d /Users/foobar/development/sites/gpi/gpi3/develop-eggs/tmp00VAgBbuild
install_dir .
install_dir .
install_dir .
install_dir .
install_dir .
install_dir .
install_dir .
install_dir .
install_dir .
install_dir .
install_dir .
install_dir .
install_dir .
install_dir .
Traceback (most recent call last):
 File "/var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/tmpXFTFnd",
line 11, in ?
   execfile('/Users/foobar/development/sites/gpi/gpi3/develop-src/foobar.wontbloodywork/setup.py')
 File "/Users/foobar/development/sites/gpi/gpi3/develop-src/foobar.wontbloodywork/setup.py",
line 56, in ?
   paster_plugins = ["ZopeSkel"],
 File "/opt/local/lib/python2.4/distutils/core.py", line 110, in setup
   _setup_distribution = dist = klass(attrs)
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/setuptools/dist.py",
line 225, in __init__
   _Distribution.__init__(self,attrs)
 File "/opt/local/lib/python2.4/distutils/dist.py", line 240, in __init__
   self.finalize_options()
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/setuptools/dist.py",
line 257, in finalize_options
   ep.require(installer=self.fetch_build_egg)
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/pkg_resources.py",
line 1966, in require
   working_set.resolve(self.dist.requires(self.extras),env,installer))
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/pkg_resources.py",
line 544, in resolve
   dist = best[req.key] = env.best_match(req, self, installer)
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/pkg_resources.py",
line 786, in best_match
   return self.obtain(req, installer) # try and download/install
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/pkg_resources.py",
line 798, in obtain
   return installer(requirement)
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/setuptools/dist.py",
line 293, in fetch_build_egg
   return cmd.easy_install(req)
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/setuptools/command/easy_install.py",
line 582, in easy_install
   return self.install_item(spec, dist.location, tmpdir, deps)
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/setuptools/command/easy_install.py",
line 612, in install_item
   dists = self.install_eggs(spec, download, tmpdir)
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/setuptools/command/easy_install.py",
line 802, in install_eggs
   return self.build_and_install(setup_script, setup_base)
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/setuptools/command/easy_install.py",
line 1079, in build_and_install
   self.run_setup(setup_script, setup_base, args)
 File "/Users/foobar/.eggs/distribute-0.6.14-py2.4.egg/setuptools/command/easy_install.py",
line 1070, in run_setup
   raise DistutilsError("Setup script exited with %s" % (v.args[0],))
distutils.errors.DistutilsError: Setup script exited with error: Setup
script exited with error: Setup script exited with error: Setup script
exited with error: Setup script exited with error: Setup script exited
with error: Setup script exited with error: Setup script exited with
error: Setup script exited with error: Setup script exited with error:
Setup script exited with error: Setup script exited with error: Setup
script exited with error:
/var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/easy_install-1srx5w/plone.app.z3cform-0.5.0/temp/easy_install-9Uu00i/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-D3fuI0/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-ZmcdZR/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-hAO4T6/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-gabkaJ/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-eev8-a/collective.z3cform.datetimewidget-1.0.2/temp/easy_install--bZxqg/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-FeERFa/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-RT9zdd/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-WaJDIy/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-7Fa2cl/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-37Xaaj/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-e_tXs0/collective.z3cform.datetimewidget-1.0.2/src/collective/z3cform/datetimewidget/locales/collective.z3cform.datetimewidget.pot:
File name too long
While:
 Installing.
 Processing develop directory
'/Users/foobar/development/sites/gpi/gpi3/develop-src/foobar.wontbloodywork'.

An internal error occured due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
 File "/private/var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/tmpZ8LHi3/zc.buildout-1.4.3-py2.4.egg/zc/buildout/buildout.py",
line 1660, in main
 File "/private/var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/tmpZ8LHi3/zc.buildout-1.4.3-py2.4.egg/zc/buildout/buildout.py",
line 394, in install
 File "/private/var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/tmpZ8LHi3/zc.buildout-1.4.3-py2.4.egg/zc/buildout/buildout.py",
line 634, in _develop
 File "/private/var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/tmpZ8LHi3/zc.buildout-1.4.3-py2.4.egg/zc/buildout/easy_install.py",
line 894, in develop
AssertionError
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100924/e7fb45b2/attachment.html>

From ziade.tarek at gmail.com  Fri Sep 24 16:05:45 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 24 Sep 2010 16:05:45 +0200
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
Message-ID: <AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>

On Fri, Sep 24, 2010 at 3:45 PM, Jon Hadley <me at jon-hadley.com> wrote:
> I'm trying to install a custom package in a buildout managed Plone 3 site in
> /develop-src named (for the sake of argument) 'foobar.wontbloodywork'.
> Yet I keep getting an error 'z3cform.datetimewidget.pot: File name too long'
> I get the same result on a freshly built Ubuntu server with no previous
> eggs. The custom packages used to install fine in an older (12 month +)
> project.
> It was suggested to me (via the Plone Users mailing list) that this might be
> a distribute error. Can anyone on this list offer any insights?

Have you tried to install that package with a raw "python setup.py
install" in your environment ?
Does it install fine ? (I am pretty sure it's not)

If not could you provide the traceback then ? If it does we will need
to trace the easy_install script to get more info when it runs that
command on that package.


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

From pje at telecommunity.com  Fri Sep 24 17:01:57 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 24 Sep 2010 11:01:57 -0400
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
 long
In-Reply-To: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
Message-ID: <20100924150156.176943A4079@sparrow.telecommunity.com>

At 02:45 PM 9/24/2010 +0100, Jon Hadley wrote:
>I'm trying to install a custom package in a buildout managed Plone 3 
>site in /develop-src named (for the sake of argument) 'foobar.wontbloodywork'.
>
>Yet I keep getting an error 'z3cform.datetimewidget.pot: File name too long'
>
>I get the same result on a freshly built Ubuntu server with no 
>previous eggs. The custom packages used to install fine in an older 
>(12 month +) project.
>
>It was suggested to me (via the Plone Users mailing list) that this 
>might be a distribute error. Can anyone on this list offer any insights?

Have you tried it using plain setuptools (0.6c11 or greater)?  There 
are some bugs in distribute regarding recursive build-time 
dependencies that were fixed in setuptools last October, but which 
are still outstanding in distribute.

 From your logs, it rather looks as though you've got a situation 
where collective.z3cform.datetimewidget has a build-time dependency 
on itself, so I'd like to know if setuptools can handle it correctly 
as well.  easy_installing the package directly works fine on my 
machine with setuptools; does distribute work for this as well?

If doing an easy_install or plain setup.py install works correctly 
with distribute, then the problem is probably in buildout rather than 
setuptools or distribute.  (I checked and the datetimewidget project 
(v1.0.2) does not declare any build-time dependencies, so there 
shouldn't be any recursion possible...  yet it appears to be taking 
place in your log nonetheless.)


From me at jon-hadley.com  Fri Sep 24 17:13:12 2010
From: me at jon-hadley.com (Jon Hadley)
Date: Fri, 24 Sep 2010 16:13:12 +0100
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>
Message-ID: <40EB3045-56D4-4C9E-A0F2-4DF7766C4B2C@jon-hadley.com>

> If not could you provide the traceback then ?

It didn't install via 'python setup.py install'. Here's the traceback:


Traceback (most recent call last):
  File "setup.py", line 57, in ?
    paster_plugins = ["ZopeSkel"],
  File "/opt/local/lib/python2.4/distutils/core.py", line 110, in setup
    _setup_distribution = dist = klass(attrs)
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/setuptools/dist.py", line 264, in __init__
    _Distribution.__init__(self,attrs)
  File "/opt/local/lib/python2.4/distutils/dist.py", line 240, in __init__
    self.finalize_options()
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/setuptools/dist.py", line 296, in finalize_options
    ep.require(installer=self.fetch_build_egg)
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/pkg_resources.py", line 1966, in require
    working_set.resolve(self.dist.requires(self.extras),env,installer))
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/pkg_resources.py", line 563, in resolve
    dist = best[req.key] = env.best_match(req, self, installer)
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/pkg_resources.py", line 799, in best_match
    return self.obtain(req, installer) # try and download/install
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/pkg_resources.py", line 811, in obtain
    return installer(requirement)
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/setuptools/dist.py", line 327, in fetch_build_egg
    return cmd.easy_install(req)
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/setuptools/command/easy_install.py", line 446, in easy_install
    return self.install_item(spec, dist.location, tmpdir, deps)
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/setuptools/command/easy_install.py", line 476, in install_item
    dists = self.install_eggs(spec, download, tmpdir)
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/setuptools/command/easy_install.py", line 655, in install_eggs
    return self.build_and_install(setup_script, setup_base)
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/setuptools/command/easy_install.py", line 930, in build_and_install
    self.run_setup(setup_script, setup_base, args)
  File "/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/setuptools-0.6c12dev_r84273-py2.4.egg/setuptools/command/easy_install.py", line 921, in run_setup
    raise DistutilsError("Setup script exited with %s" % (v.args[0],))
distutils.errors.DistutilsError: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: /var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/easy_install-0sQo4n/plone.app.z3cform-0.5.0/temp/easy_install-7sGfXW/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-al8Yxz/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-w2eUm4/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-5rw4gK/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-Ye6gh_/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-VEw7cI/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-Q1eWho/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-G19SyU/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-i4SgrW/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-V9zFKN/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-MG4zvv/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-T-UGiD/collective.z3cform.datetimewidget-1.0.2/temp/easy_install-RPH3h0/collective.z3cform.datetimewidget-1.0.2/src/collective/z3cform/datetimewidget/locales/collective.z3cform.datetimewidget.pot: File name too long


From ziade.tarek at gmail.com  Fri Sep 24 17:13:30 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 24 Sep 2010 17:13:30 +0200
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <20100924150156.176943A4079@sparrow.telecommunity.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<20100924150156.176943A4079@sparrow.telecommunity.com>
Message-ID: <AANLkTinNZpj7Fi6wFOkvs+f55Zy6jm3RnRcX1e=hrJHD@mail.gmail.com>

On Fri, Sep 24, 2010 at 5:01 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 02:45 PM 9/24/2010 +0100, Jon Hadley wrote:
>>
>> I'm trying to install a custom package in a buildout managed Plone 3 site
>> in /develop-src named (for the sake of argument) 'foobar.wontbloodywork'.
>>
>> Yet I keep getting an error 'z3cform.datetimewidget.pot: File name too
>> long'
>>
>> I get the same result on a freshly built Ubuntu server with no previous
>> eggs. The custom packages used to install fine in an older (12 month +)
>> project.
>>
>> It was suggested to me (via the Plone Users mailing list) that this might
>> be a distribute error. Can anyone on this list offer any insights?
>
> Have you tried it using plain setuptools (0.6c11 or greater)? ?There are
> some bugs in distribute regarding recursive build-time dependencies that
> were fixed in setuptools last October, but which are still outstanding in
> distribute.

Please can you point us to the issue in the tracker and the commit
where that fix happened ?

I'd be glad to fix it if this happens to be true.

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

From ziade.tarek at gmail.com  Fri Sep 24 17:16:07 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 24 Sep 2010 17:16:07 +0200
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <40EB3045-56D4-4C9E-A0F2-4DF7766C4B2C@jon-hadley.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>
	<40EB3045-56D4-4C9E-A0F2-4DF7766C4B2C@jon-hadley.com>
Message-ID: <AANLkTim0uC4N04bHbUj93BC_v7i5DsSjihzagcr9o6Sr@mail.gmail.com>

On Fri, Sep 24, 2010 at 5:13 PM, Jon Hadley <me at jon-hadley.com> wrote:
>> If not could you provide the traceback then ?
>
> It didn't install via 'python setup.py install'. Here's the traceback:

It looks like you have a trunk version of Setuptools here, not
Distribute.  What precise package should I download from PyPI to try
myself on a fresh Distribute install ?

Tarek

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

From me at jon-hadley.com  Fri Sep 24 17:25:30 2010
From: me at jon-hadley.com (Jon Hadley)
Date: Fri, 24 Sep 2010 16:25:30 +0100
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <20100924150156.176943A4079@sparrow.telecommunity.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<20100924150156.176943A4079@sparrow.telecommunity.com>
Message-ID: <8EFD1631-62A1-481B-AC0A-489CB522B005@jon-hadley.com>

> Have you tried it using plain setuptools (0.6c11 or greater)?  

I'm using 0.6c12dev (according to the traceback).

> easy_installing the package directly works fine on my machine with setuptools;

Similar error here with easy_install:

Best match: fez.atcsv 0.2
Processing fez.atcsv-0.2-py2.4.egg
fez.atcsv 0.2 is already the active version in easy-install.pth

Using /Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/fez.atcsv-0.2-py2.4.egg
Processing dependencies for fez.atcsv
Searching for zope.interface
Reading http://pypi.python.org/simple/zope.interface/
Best match: zope.interface 3.6.1
Downloading http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.6.1.tar.gz#md5=7a895181b8d10be4a7e9a3afa13cd3be
Processing zope.interface-3.6.1.tar.gz
Running zope.interface-3.6.1/setup.py -q bdist_egg --dist-dir /var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/easy_install-WbqHry/zope.interface-3.6.1/egg-dist-tmp-3nTDSI
error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: Setup script exited with error: /var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/easy_install-WbqHry/zope.interface-3.6.1/temp/easy_install-zCqg_j/zope.interface-3.6.1/temp/easy_install-BMwk4f/zope.interface-3.6.1/temp/easy_install-3cf4q3/zope.interface-3.6.1/temp/easy_install-qq9hdi/zope.interface-3.6.1/temp/easy_install-1YuNjW/zope.interface-3.6.1/temp/easy_install-UFBQy3/zope.interface-3.6.1/temp/easy_install-5iJ_Iz/zope.interface-3.6.1/temp/easy_install-EUYmlj/zope.interface-3.6.1/temp/easy_install-Fb6CP_/zope.interface-3.6.1/temp/easy_install-xxEDGH/zope.interface-3.6.1/temp/easy_install-VWbLfl/zope.interface-3.6.1/temp/easy_install-h0wTxV/zope.interface-3.6.1/temp/easy_install-atbmIa/zope.interface-3.6.1/temp/easy_install-PmspAW/zope.interface-3.6.1/temp/easy_install--YMDu6/zope.interface-3.6.1/temp/easy_install-pUOez5/zope.interface-3.6.1/temp/easy_install-huEA2x/zope.interface-3.6.1/temp/easy_install-wMJuwp/zope.interface-3.6.1/temp/easy_install-rlKxe4/zope.interface-3.6.1/src/zope/interface/common/tests/test_import_interfaces.py: File name too long

> does distribute work for this as well?

I'm not completely clear how to test this. I'm working in a virtualenv which has been 'bootstrapped with the python bootstrap.py -d' option - does that make setuptools a distribute fork?

Thanks for your help,

Jon

From me at jon-hadley.com  Fri Sep 24 17:20:10 2010
From: me at jon-hadley.com (Jon Hadley)
Date: Fri, 24 Sep 2010 16:20:10 +0100
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <AANLkTim0uC4N04bHbUj93BC_v7i5DsSjihzagcr9o6Sr@mail.gmail.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>
	<40EB3045-56D4-4C9E-A0F2-4DF7766C4B2C@jon-hadley.com>
	<AANLkTim0uC4N04bHbUj93BC_v7i5DsSjihzagcr9o6Sr@mail.gmail.com>
Message-ID: <A6BF77FF-DCB9-4999-917E-E9812C42F7F0@jon-hadley.com>

> What precise package should I download from PyPI to try
> myself on a fresh Distribute install ?

http://pypi.python.org/pypi/fez.atcsv/0.2

Thanks Tarek,

Jon.

From ziade.tarek at gmail.com  Fri Sep 24 17:53:12 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 24 Sep 2010 17:53:12 +0200
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <A6BF77FF-DCB9-4999-917E-E9812C42F7F0@jon-hadley.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>
	<40EB3045-56D4-4C9E-A0F2-4DF7766C4B2C@jon-hadley.com>
	<AANLkTim0uC4N04bHbUj93BC_v7i5DsSjihzagcr9o6Sr@mail.gmail.com>
	<A6BF77FF-DCB9-4999-917E-E9812C42F7F0@jon-hadley.com>
Message-ID: <AANLkTin0NxgLtsWCmSGVY=PRe5YD=xEYY4TB3gQzaQ-9@mail.gmail.com>

On Fri, Sep 24, 2010 at 5:20 PM, Jon Hadley <me at jon-hadley.com> wrote:
>> What precise package should I download from PyPI to try
>> myself on a fresh Distribute install ?
>
> http://pypi.python.org/pypi/fez.atcsv/0.2

I found the bug: every time a dependency is to be installed it's
recursively uncompressed in the previous tmp directory. So after a
while, you get dead long paths and get your bug.

Working on a fix tonite.



>
> Thanks Tarek,
>
> Jon.
>



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

From pje at telecommunity.com  Fri Sep 24 21:07:04 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 24 Sep 2010 15:07:04 -0400
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
 long
In-Reply-To: <8EFD1631-62A1-481B-AC0A-489CB522B005@jon-hadley.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<20100924150156.176943A4079@sparrow.telecommunity.com>
	<8EFD1631-62A1-481B-AC0A-489CB522B005@jon-hadley.com>
Message-ID: <20100924190707.D10DC3A4079@sparrow.telecommunity.com>

At 04:25 PM 9/24/2010 +0100, Jon Hadley wrote:
>Similar error here with easy_install:
>
>Best match: fez.atcsv 0.2
>Processing fez.atcsv-0.2-py2.4.egg
>fez.atcsv 0.2 is already the active version in easy-install.pth
>
>Using 
>/Users/foobar/development/sites/gpi/gpi3/lib/python2.4/site-packages/fez.atcsv-0.2-py2.4.egg
>Processing dependencies for fez.atcsv
>Searching for zope.interface
>Reading http://pypi.python.org/simple/zope.interface/
>Best match: zope.interface 3.6.1
>Downloading 
>http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.6.1.tar.gz#md5=7a895181b8d10be4a7e9a3afa13cd3be
>Processing zope.interface-3.6.1.tar.gz
>Running zope.interface-3.6.1/setup.py -q bdist_egg --dist-dir 
>/var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/easy_install-WbqHry/zope.interface-3.6.1/egg-dist-tmp-3nTDSI
>error: Setup script exited with error: Setup script exited with 
>error: Setup script exited with error: Setup script exited with 
>error: Setup script exited with error: Setup script exited with 
>error: Setup script exited with error: Setup script exited with 
>error: Setup script exited with error: Setup script exited with 
>error: Setup script exited with error: Setup script exited with 
>error: Setup script exited with error: Setup script exited with 
>error: Setup script exited with error: Setup script exited with 
>error: Setup script exited with error: Setup script exited with 
>error: Setup script exited with error: 
>/var/folders/N1/N1WTRWwWE5Gfqr-Sut+UVk+++TM/-Tmp-/easy_install-WbqHry/zope.interface-3.6.1/temp/easy_install-zCqg_j/zope.interface-3.6.1/temp/easy_install-BMwk4f/zope.interface-3.6.1/temp/easy_install-3cf4q3/zope.interface-3.6.1/temp/easy_install-qq9hdi/zope.interface-3.6.1/temp/easy_install-1YuNjW/zope.interface-3.6.1/temp/easy_install-UFBQy3/zope.interface-3.6.1/temp/easy_install-5iJ_Iz/zope.interface-3.6.1/temp/easy_install-EUYmlj/zope.interface-3.6.1/temp/easy_install-Fb6CP_/zope.interface-3.6.1/temp/easy_install-xxEDGH/zope.interface-3.6.1/temp/easy_install-VWbLfl/zope.interface-3.6.1/temp/easy_install-h0wTxV/zope.interface-3.6.1/temp/easy_install-atbmIa/zope.interface-3.6.1/temp/easy_install-PmspAW/zope.interface-3.6.1/temp/easy_install--YMDu6/zope.interface-3.6.1/temp/easy_install-pUOez5/zope.interface-3.6.1/temp/easy_install-huEA2x/zope.interface-3.6.1/temp/easy_install-wMJuwp/zope.interface-3.6.1/temp/easy_install-rlKxe4/zope.interface-3.6.1/src/zope/interface/commo
 n/tes
ts 
>/test_import_interfaces.py: File name too long

Hm.  I'm not able to reproduce this, with either install or 
easy_install, on setuptools 0.6 or 0.7, on Python 2.4 or 2.5, on 
Windows or Linux.  Have you tried it *without* a virtualenv, i.e.:

    /path/to/the/real/python easy_install -md somedir fez.atcsv

?

(By the way, it appears that one problem you may be encountering 
anyway is that several of the packages you're trying to install do 
not support Python version 2.4, and have many syntax errors during 
the build process.)


> > does distribute work for this as well?
>
>I'm not completely clear how to test this. I'm working in a 
>virtualenv which has been 'bootstrapped with the python bootstrap.py 
>-d' option - does that make setuptools a distribute fork?

It's the other way around, actually.  Distribute is a fork of setuptools.



From pje at telecommunity.com  Fri Sep 24 21:18:17 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 24 Sep 2010 15:18:17 -0400
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
 long
In-Reply-To: <AANLkTinNZpj7Fi6wFOkvs+f55Zy6jm3RnRcX1e=hrJHD@mail.gmail.c
 om>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<20100924150156.176943A4079@sparrow.telecommunity.com>
	<AANLkTinNZpj7Fi6wFOkvs+f55Zy6jm3RnRcX1e=hrJHD@mail.gmail.com>
Message-ID: <20100924191817.1E0583A4079@sparrow.telecommunity.com>

At 05:13 PM 9/24/2010 +0200, Tarek Ziad? wrote:
>On Fri, Sep 24, 2010 at 5:01 PM, P.J. Eby <pje at telecommunity.com> wrote:
> > Have you tried it using plain setuptools (0.6c11 or greater)?  There are
> > some bugs in distribute regarding recursive build-time dependencies that
> > were fixed in setuptools last October, but which are still outstanding in
> > distribute.
>
>Please can you point us to the issue in the tracker and the commit
>where that fix happened ?
>
>I'd be glad to fix it if this happens to be true.

http://mail.python.org/pipermail/distutils-sig/2009-October/013823.html


From pje at telecommunity.com  Fri Sep 24 21:22:19 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 24 Sep 2010 15:22:19 -0400
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
 long
Message-ID: <20100924192218.D25563A4079@sparrow.telecommunity.com>

At 05:53 PM 9/24/2010 +0200, Tarek Ziad? wrote:
>On Fri, Sep 24, 2010 at 5:20 PM, Jon Hadley <me at jon-hadley.com> wrote:
> >> What precise package should I download from PyPI to try
> >> myself on a fresh Distribute install ?
> >
> > http://pypi.python.org/pypi/fez.atcsv/0.2
>
>I found the bug: every time a dependency is to be installed it's
>recursively uncompressed in the previous tmp directory. So after a
>while, you get dead long paths and get your bug.
>
>Working on a fix tonite.

The real WTF here is that the same package is being repeatedly 
downloaded and installed as its own dependency repeatedly -- it's 
unlikely that fixing the temp directory processing will fix *that* 
problem, unless by some chance that accidentally makes the package 
recognize itself.


From ziade.tarek at gmail.com  Fri Sep 24 21:50:23 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 24 Sep 2010 21:50:23 +0200
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <20100924191817.1E0583A4079@sparrow.telecommunity.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<20100924150156.176943A4079@sparrow.telecommunity.com>
	<AANLkTinNZpj7Fi6wFOkvs+f55Zy6jm3RnRcX1e=hrJHD@mail.gmail.com>
	<20100924191817.1E0583A4079@sparrow.telecommunity.com>
Message-ID: <AANLkTimgxEWPCUTjGDNU-wr1-Rv8tK4ekde9vTM85F11@mail.gmail.com>

On Fri, Sep 24, 2010 at 9:18 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 05:13 PM 9/24/2010 +0200, Tarek Ziad? wrote:
>>
>> On Fri, Sep 24, 2010 at 5:01 PM, P.J. Eby <pje at telecommunity.com> wrote:
>> > Have you tried it using plain setuptools (0.6c11 or greater)? ?There are
>> > some bugs in distribute regarding recursive build-time dependencies that
>> > were fixed in setuptools last October, but which are still outstanding
>> > in
>> > distribute.
>>
>> Please can you point us to the issue in the tracker and the commit
>> where that fix happened ?
>>
>> I'd be glad to fix it if this happens to be true.
>
> http://mail.python.org/pipermail/distutils-sig/2009-October/013823.html

Yes, that still stands.  I am curious to see that fix (issue+commit)
and I'd be glad to fix it if this happens to be true.

Or this is a secret fix of yours, hidden in some kind of big commit
without any comment or test ? :)

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

From ziade.tarek at gmail.com  Fri Sep 24 23:40:18 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 24 Sep 2010 23:40:18 +0200
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <AANLkTin0NxgLtsWCmSGVY=PRe5YD=xEYY4TB3gQzaQ-9@mail.gmail.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>
	<40EB3045-56D4-4C9E-A0F2-4DF7766C4B2C@jon-hadley.com>
	<AANLkTim0uC4N04bHbUj93BC_v7i5DsSjihzagcr9o6Sr@mail.gmail.com>
	<A6BF77FF-DCB9-4999-917E-E9812C42F7F0@jon-hadley.com>
	<AANLkTin0NxgLtsWCmSGVY=PRe5YD=xEYY4TB3gQzaQ-9@mail.gmail.com>
Message-ID: <AANLkTikpd6P0cqaD+3CAf0b_cLgcV0cTDP_JU2qV5BCq@mail.gmail.com>

I can reproduce this issue with setuptools 0.6c11 and (0.6 branch)
trunk and Distribute in a virtualenv under 2.6, so this is definitely
an existing bug in all versions.  It's looping on one dependency and I
don't know why yet, it's quite hard to debug and understand.

The fix that was done some time ago to keep the working env state is
not working for that case. I will continue to look for the problem in
the upcoming days.

Tarek

On Fri, Sep 24, 2010 at 5:53 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Fri, Sep 24, 2010 at 5:20 PM, Jon Hadley <me at jon-hadley.com> wrote:
>>> What precise package should I download from PyPI to try
>>> myself on a fresh Distribute install ?
>>
>> http://pypi.python.org/pypi/fez.atcsv/0.2
>
> I found the bug: every time a dependency is to be installed it's
> recursively uncompressed in the previous tmp directory. So after a
> while, you get dead long paths and get your bug.
>
> Working on a fix tonite.
>
>
>
>>
>> Thanks Tarek,
>>
>> Jon.
>>
>
>
>
> --
> Tarek Ziad? | http://ziade.org
>



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

From techtonik at gmail.com  Sat Sep 25 20:41:23 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 25 Sep 2010 21:41:23 +0300
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <20100921103424.745016d4@mission>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
	<20100921103424.745016d4@mission>
Message-ID: <AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>

On Tue, Sep 21, 2010 at 5:34 PM, Barry Warsaw <barry at python.org> wrote:
>
> Yes it should definitely use doc/ if docs/ is missing.

Attached patch. Review in context at http://codereview.appspot.com/2269042

> However, upload_docs
> never quite works out of the box for me anyway. ?First, it insists on an
> index.html file, which my Sphinx builds never seem to write, so I always have
> to add a symlink. ?Second, it doesn't seem to play nicely with the location
> that my buildout-based builds puts the docs, so I always also have to use
> --upload-dir. ?Yes, it would be nice if both of these problems were fixed too.
> Yes, I should report them as bugs (or just fix 'em ;).

Well, I may think that I've fixed my problem, but until fix is
integrated, I can't tell.
--
anatoly t.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upload_docs.doc.patch
Type: application/octet-stream
Size: 1617 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100925/d7a35ba2/attachment.obj>

From techtonik at gmail.com  Sat Sep 25 21:04:12 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Sat, 25 Sep 2010 22:04:12 +0300
Subject: [Distutils] please fix easy_install shorter URL preference
 (Was: easy_install wrong download site preference)
In-Reply-To: <20100918230510.B07643A403D@sparrow.telecommunity.com>
References: <AANLkTi=LJ-JrfXTmZzpuCjxnmY=SZH1bhbNTnkEXMpCW@mail.gmail.com>
	<20100912180857.370603A40F5@sparrow.telecommunity.com>
	<AANLkTi=QtRk_JK6_UOv5OE7B2vM2+v8oXtFkxZ270Q=u@mail.gmail.com>
	<20100918230510.B07643A403D@sparrow.telecommunity.com>
Message-ID: <AANLkTi=DvjpLp0-S_RUHxO76w9vtC7VmJDOAOoR4Gw0e@mail.gmail.com>

On Sun, Sep 19, 2010 at 2:04 AM, P.J. Eby <pje at telecommunity.com> wrote:
>
> This should give you 0.6c12dev-r_something_or_other. ?;-)

Ok. SF .egg installation from /download URL is fixed. But the logic to
prefer shorter URL is not.

>> > Note, however, that since the full source distribution *also* includes
>> > the
>> > python code, all that's needed is to change its setup.py slightly and
>> > move
>> > it to the root of the source tree.
>>
>> If the Python was the only code inside - that'd be acceptable, but it
>> seems like the proper fix lies in setuptools AI code.
>
> You do realize that asking everybody to update their version of setuptools
> in order to be able to install one particular package is a little
> unrealistic? ?I mean, *your* setuptools is at least seven months out of
> date, so even if I changed this, how long would it be till your users
> updated? ?;-)

1. s/everybody/package users/
2. s/order/installation instructions/
3. s/particular/this/

Yes. I realize that it is much easier to set setuptools requirements
once that to download manually from PyPI everytime.

> In truth, I do have an idea that would actually fix this problem in the
> Google case (a change to the way the source is processed after extraction),

For the start it will help if 'easy_install' download package from
PyPI if download_url for this package is not set. I understand that
fix to remove shorter URL preference logic is too complicated, so
perhaps it will be easier to implement this solution.

> but it will likely be a while before I can implement it, and a while further
> still before everyone has installed the update. ?(Note that 0.6c5 and 0.6c9
> are still very popular versions, and 0.6c9 is like *two years* out of date.)

This won't be a problem two years later if you fix the issue today. =)
-- 
anatoly t.

From me at jon-hadley.com  Sat Sep 25 21:43:47 2010
From: me at jon-hadley.com (Jon Hadley)
Date: Sat, 25 Sep 2010 20:43:47 +0100
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <AANLkTikpd6P0cqaD+3CAf0b_cLgcV0cTDP_JU2qV5BCq@mail.gmail.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>
	<40EB3045-56D4-4C9E-A0F2-4DF7766C4B2C@jon-hadley.com>
	<AANLkTim0uC4N04bHbUj93BC_v7i5DsSjihzagcr9o6Sr@mail.gmail.com>
	<A6BF77FF-DCB9-4999-917E-E9812C42F7F0@jon-hadley.com>
	<AANLkTin0NxgLtsWCmSGVY=PRe5YD=xEYY4TB3gQzaQ-9@mail.gmail.com>
	<AANLkTikpd6P0cqaD+3CAf0b_cLgcV0cTDP_JU2qV5BCq@mail.gmail.com>
Message-ID: <905BBF89-22C7-49D3-B1DB-9B44898BCFB6@jon-hadley.com>

> It's looping on one dependency and I don't know why yet, it's quite hard to debug and understand.

What are my options in the meantime? The bug is stopping my package from installing and my buildout completing.

You mention it exists in all versions, so I can't downgrade to get round it? Is there something unique to my package that could be re-written to avoid the bug for now?

Thanks for your work so far,

Jon.

From pje at telecommunity.com  Sat Sep 25 22:14:40 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sat, 25 Sep 2010 16:14:40 -0400
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
 long
In-Reply-To: <905BBF89-22C7-49D3-B1DB-9B44898BCFB6@jon-hadley.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>
	<40EB3045-56D4-4C9E-A0F2-4DF7766C4B2C@jon-hadley.com>
	<AANLkTim0uC4N04bHbUj93BC_v7i5DsSjihzagcr9o6Sr@mail.gmail.com>
	<A6BF77FF-DCB9-4999-917E-E9812C42F7F0@jon-hadley.com>
	<AANLkTin0NxgLtsWCmSGVY=PRe5YD=xEYY4TB3gQzaQ-9@mail.gmail.com>
	<AANLkTikpd6P0cqaD+3CAf0b_cLgcV0cTDP_JU2qV5BCq@mail.gmail.com>
	<905BBF89-22C7-49D3-B1DB-9B44898BCFB6@jon-hadley.com>
Message-ID: <20100925201441.E61253A4079@sparrow.telecommunity.com>

At 08:43 PM 9/25/2010 +0100, Jon Hadley wrote:
>What are my options in the meantime? The bug is stopping my package 
>from installing and my buildout completing.
>
>You mention it exists in all versions, so I can't downgrade to get 
>round it? Is there something unique to my package that could be 
>re-written to avoid the bug for now?

I think I know what the problem is.  I re-examined your traceback, 
and the place where it's trying a recursive install is on looking up 
the entry point for a setup() argument.  That is, it's trying to load 
a plugin to handle a setup() argument.

This would explain why I can't reproduce the problem, since I don't 
have the same plugin(s) as you.

So, could you please try it *without* buildout or virtualenv?

Specifically, try running:

    /path/to/the/real/python2.4 -m easy_install -mad somedir fez.atcsv

Where 'somedir' is a new, empty directory, and 
/path/to/the/real/python2.4 is NOT a virtualenv Python, and see what happens.

You won't need root access, as with the -mad options easy_install 
will not write outside of 'somedir' and your system tmp directory.

If this does *not* get into the same build loop, then the problem 
likely lies with a plugin in your virtualenv, or that ends up on 
sys.path while buildout is running.

We can then narrow it down to what specific plugin is causing the 
problem, by running something like this code in the virtualenv (or on 
the main Python, if the problem is also there):

     for ep in pkg_resources.iter_entry_points('distutils.setup_keywords'):
         print ep.name, ep.dist, ep.extras

This will dump out what plugins are providing what keywords, and what 
requirements they depend on, and will help us find where the problem is.


From pje at telecommunity.com  Mon Sep 27 01:18:36 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Sun, 26 Sep 2010 19:18:36 -0400
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
 long
In-Reply-To: <AANLkTimWs5QsBnzKX9KBP=DfVGtOSGNKa3xg_ZfcLos0@mail.gmail.c
 om>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>
	<40EB3045-56D4-4C9E-A0F2-4DF7766C4B2C@jon-hadley.com>
	<AANLkTim0uC4N04bHbUj93BC_v7i5DsSjihzagcr9o6Sr@mail.gmail.com>
	<A6BF77FF-DCB9-4999-917E-E9812C42F7F0@jon-hadley.com>
	<AANLkTin0NxgLtsWCmSGVY=PRe5YD=xEYY4TB3gQzaQ-9@mail.gmail.com>
	<AANLkTikpd6P0cqaD+3CAf0b_cLgcV0cTDP_JU2qV5BCq@mail.gmail.com>
	<905BBF89-22C7-49D3-B1DB-9B44898BCFB6@jon-hadley.com>
	<20100925201441.E61253A4079@sparrow.telecommunity.com>
	<AANLkTimWs5QsBnzKX9KBP=DfVGtOSGNKa3xg_ZfcLos0@mail.gmail.com>
Message-ID: <20100926231833.3A2313A411A@sparrow.telecommunity.com>

Fascinating.  It appears as though your virtualenv has both 
distribute 0.6.14 *and* setuptools 0.6c12dev on sys.path at the same 
time.  However, I'm most curious about this one:

At 10:52 PM 9/26/2010 +0100, Jon Hadley wrote:
>paster_plugins fez.atcsv 0.3 ()

This looks like an error to me, and one that *could* create the 
behavior being seen.  Your app should not be defining the 
paster_plugins entry point; instead, you are supposed to just have a 
setup_requires=['PasteScript'] in order to take care of it.

What is probably happening now is that your package is claiming it 
implements this keyword argument, so any project that is built with 
your project on sys.path that uses this keyword (such as your own 
proejct) will try to add your project's runtime dependencies (i.e. 
setuptools and plone.app.z3cform) to sys.path.  So, it tries to build 
those dependencies first.

However, at that point, it appears fez.atcsv is *also* providing an 
entry point for the paster_plugins.txt egg-info writer...  which is 
even worse, because it affects *every* app built, not just ones that 
use the paster_plugins setup() keyword.

So, as soon as the dependency tries to build, it wants to have 
fez.atcsv built...  so it tries to build fez.atcsv's 
dependencies...  and so on, and so on, indefinitely.

Here's how to fix the problem:

First, remove all fez.atcsv-*.egg files or directories -- 
EVERYWHERE.  Delete every last one off the system, no matter where it is.

Second, remove the entry_points.txt file from the fez.atcsv.egg-info/ 
directory within your project source.

Third and finally, remove the entire entry_points keyword from your 
setup() call in setup.py, and replace it with setup_requires=['PasteScript'].

This would probably be sufficient to fix the problem if setuptools 
were first on your sys.path, since it has fixes for PasteScript's 
internal build recursion; I do not know if it will fix the problem 
with distribute, unless you first make sure PasteScript's 
dependencies are all installed.

However, I'm pretty certain at this point that the bogus entry_points 
in your setup.py is the source of the entire problem, and explains 
why I could not reproduce it (as at no point would a copy of the 
broken fez.atcsv have been on my sys.path during any of my attempts, 
whereas it presumably was during most if not all of yours).


From ziade.tarek at gmail.com  Mon Sep 27 09:47:12 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 27 Sep 2010 09:47:12 +0200
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTinJr2awGhh0MOpBTCAuJ0B6ahzjrTn2SMH+N0=H@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
	<AANLkTinJr2awGhh0MOpBTCAuJ0B6ahzjrTn2SMH+N0=H@mail.gmail.com>
Message-ID: <AANLkTikqOsnsHv9wJYLSxH_F6V9mp=iDi8iRM+uoDyn2@mail.gmail.com>

On Tue, Sep 21, 2010 at 4:38 PM, Fred Drake <fdrake at acm.org> wrote:
> On Tue, Sep 21, 2010 at 10:20 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>> upload_docs command will extract documentation from 'docs/' by
>> default. I wouldn't bring this question if it could also process
>> 'doc/' in cases where 'docs/' are absent. You can specify upload
>> directory explicitly, but sometimes you'd really like it to just work.
>
> Of course, we'd have to define what "just work" means here. ?I'd be
> fine having to always tell upload_docs where to look, provided I can
> do that in the setup.cfg d2 uses.
>
> That said, I don't *mind* if it looks for both docs/ and doc/, or even
> care which it looks for first.

+1 -- trying both seems fine as I don't think we want to push hard on
any convention here.

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

From ziade.tarek at gmail.com  Mon Sep 27 09:55:13 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 27 Sep 2010 09:55:13 +0200
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
	<20100921103424.745016d4@mission>
	<AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>
Message-ID: <AANLkTinCK-oVcrs+rTbn893XD5BCkJXMCB2VCrsui9YC@mail.gmail.com>

On Sat, Sep 25, 2010 at 8:41 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Tue, Sep 21, 2010 at 5:34 PM, Barry Warsaw <barry at python.org> wrote:
>>
>> Yes it should definitely use doc/ if docs/ is missing.
>
> Attached patch. Review in context at http://codereview.appspot.com/2269042

Thanks for the diff. Would you mind adding a tiny little test in
test_upload_docs.test_default_uploaddir

I'll be happy to merge tour change then.

>
>> However, upload_docs
>> never quite works out of the box for me anyway. ?First, it insists on an
>> index.html file, which my Sphinx builds never seem to write, so I always have
>> to add a symlink.

Barry, do you mean that you have all files generated by Sphinx but not
index.html ? That's weird, Sphinx should generate it like the others.

> ?Second, it doesn't seem to play nicely with the location
>> that my buildout-based builds puts the docs, so I always also have to use
>> --upload-dir. ?Yes, it would be nice if both of these problems were fixed too.
>> Yes, I should report them as bugs (or just fix 'em ;).

How would you fix the second issue ? e.g. if the docs is not in docs/ or doc/

Regards
Tarek

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

From me at jon-hadley.com  Mon Sep 27 11:27:45 2010
From: me at jon-hadley.com (Jon Hadley)
Date: Mon, 27 Sep 2010 10:27:45 +0100
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <20100926231833.3A2313A411A@sparrow.telecommunity.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>
	<40EB3045-56D4-4C9E-A0F2-4DF7766C4B2C@jon-hadley.com>
	<AANLkTim0uC4N04bHbUj93BC_v7i5DsSjihzagcr9o6Sr@mail.gmail.com>
	<A6BF77FF-DCB9-4999-917E-E9812C42F7F0@jon-hadley.com>
	<AANLkTin0NxgLtsWCmSGVY=PRe5YD=xEYY4TB3gQzaQ-9@mail.gmail.com>
	<AANLkTikpd6P0cqaD+3CAf0b_cLgcV0cTDP_JU2qV5BCq@mail.gmail.com>
	<905BBF89-22C7-49D3-B1DB-9B44898BCFB6@jon-hadley.com>
	<20100925201441.E61253A4079@sparrow.telecommunity.com>
	<AANLkTimWs5QsBnzKX9KBP=DfVGtOSGNKa3xg_ZfcLos0@mail.gmail.com>
	<20100926231833.3A2313A411A@sparrow.telecommunity.com>
Message-ID: <630BEF9E-D40F-436F-A14A-2358EF5FA8C3@jon-hadley.com>

On 27 Sep 2010, at 00:18, P.J. Eby wrote:
> Here's how to fix the problem

Your suggested fix worked great, thanks for the explanation.

This implies, I assume, that the 'bug' Tarek found is in how setuptools/distribute deals with a mistake in my package, as opposed to a full blown bug causing my original error.

Thank you both P.J. and Tarek for your dogged attention to this issue - I very much appreciate your help.

Cheers,

Jon Hadley

From ziade.tarek at gmail.com  Mon Sep 27 12:16:14 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 27 Sep 2010 12:16:14 +0200
Subject: [Distutils] Distribute error? datetimewidget.pot: File name too
	long
In-Reply-To: <630BEF9E-D40F-436F-A14A-2358EF5FA8C3@jon-hadley.com>
References: <649BF036-6F78-4794-A077-4BD0DF31072F@jon-hadley.com>
	<AANLkTi=Og+d==y3_6eNO0wttN0SDcK7DVvRyxw_pG7Ye@mail.gmail.com>
	<40EB3045-56D4-4C9E-A0F2-4DF7766C4B2C@jon-hadley.com>
	<AANLkTim0uC4N04bHbUj93BC_v7i5DsSjihzagcr9o6Sr@mail.gmail.com>
	<A6BF77FF-DCB9-4999-917E-E9812C42F7F0@jon-hadley.com>
	<AANLkTin0NxgLtsWCmSGVY=PRe5YD=xEYY4TB3gQzaQ-9@mail.gmail.com>
	<AANLkTikpd6P0cqaD+3CAf0b_cLgcV0cTDP_JU2qV5BCq@mail.gmail.com>
	<905BBF89-22C7-49D3-B1DB-9B44898BCFB6@jon-hadley.com>
	<20100925201441.E61253A4079@sparrow.telecommunity.com>
	<AANLkTimWs5QsBnzKX9KBP=DfVGtOSGNKa3xg_ZfcLos0@mail.gmail.com>
	<20100926231833.3A2313A411A@sparrow.telecommunity.com>
	<630BEF9E-D40F-436F-A14A-2358EF5FA8C3@jon-hadley.com>
Message-ID: <AANLkTikCTjc6zF92JXiOsCww-BKx+3pf8BKCX-WGXxbb@mail.gmail.com>

2010/9/27 Jon Hadley <me at jon-hadley.com>:
> On 27 Sep 2010, at 00:18, P.J. Eby wrote:
>> Here's how to fix the problem
>
> Your suggested fix worked great, thanks for the explanation.
>
> This implies, I assume, that the 'bug' Tarek found is in how setuptools/distribute deals with a mistake in my package, as opposed to a full blown bug causing my original error.

Well the recursive call is a side-effect of your (mis)configuration. I
am pretty sure we can avoid this and raise an error that is less
cryptic, but I am not sure how to properly do it yet.

Tarek

From intuited at gmail.com  Wed Sep 22 01:01:25 2010
From: intuited at gmail.com (Ted Tibbetts)
Date: Tue, 21 Sep 2010 20:01:25 -0300
Subject: [Distutils] [issue117] Unable to upload package without storing
 password in ~/.pypirc
In-Reply-To: <AANLkTinPm+QD+EzUbvLnWVs7KBc6ZkFsmhcBnV8x4dCi@mail.gmail.com>
References: <1285107024.23.0.44730822147.issue117@psf.upfronthosting.co.za>
	<AANLkTinPm+QD+EzUbvLnWVs7KBc6ZkFsmhcBnV8x4dCi@mail.gmail.com>
Message-ID: <AANLkTinBK5VjC_Pur0aV95uX4vfBkVXfR+-8i_5mU30m@mail.gmail.com>

Hi,
  Strike two for me then :)  Thanks for the pointer.  It's difficult to know
which bits are being handled by ``setuptools`` and which are just being
handed off to ``distutils``, and whether ``setuptools`` purports to
perfectly replicate all of the ``distutils`` functionality.

  IIRC, I wanted to test the upload under distutils, but couldn't because
the sdist builds differently under distutils, and it seems to be required to
build the sdist as part of the ``upload`` command.  I guess I *could* have
tested it, but it would have required sending a bogus package version out to
PyPI, assuming that it worked.  Is there maybe a dummy server available for
testing these sorts of things?

  It looks like this is the fix you mentioned: `<
http://bugs.python.org/issue4394>`_.  The thread for that issue
mentions<http://bugs.python.org/issue4394#msg79428>that it was
committed for Python 2.7.

  I'm running Python 2.6.5; more specifically the package from ubuntu 10.04,
which has a version number of ``2.6.5-0ubuntu1``.

  I'm not sure if this is my bad for using documentation which doesn't match
my version number (i.e. the currently posted documentation at
http://docs.python.org/distutils/uploading.html#package-upload), or if the
documentation should make a note that that particular feature is new to
python 2.7.

  My apologies for misdirecting my issue; I'm just learning Python packaging
and it's a bit confusing to sort out what's in distutils, what's in
setuptools, and what's in the distribute module which was previously
installed on my system, "masquerading", as it were. as setuptools.

  The documentation for setuptools does seem to be a bit out of date: for
instance,
http://peak.telecommunity.com/DevCenter/setuptools#building-and-distributing-packages-with-setuptools
lists
as one of its features "PyPI upload support - upload your source
distributions and eggs to PyPI".  However, it would appear that this
functionality has since been rolled into distutils.

  Anyhow, thank you kindly for the quick response and for all your work on
these modules, I guess I just have to deal with this password issue the
annoying way until I update to Python 2.7.

  Cheers

-Ted

On Tue, Sep 21, 2010 at 7:24 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> This is not related to setuptools but to Distutils so you should file
> an issue at bugs.python.org instead.
>
> IIRC I have fixed this in 2.6. What is your Python version ?
>
>
> On Wed, Sep 22, 2010 at 12:10 AM, Ted Tibbetts
> <setuptools at bugs.python.org> wrote:
> >
> > New submission from Ted Tibbetts <intuited at gmail.com>:
> >
> > I can't seem to upload a source distribution without storing my password
> in ~/.pypirc.
> >
> > If I have no ~/.pypirc, and I give a the command
> >
> >    ``$ python setup.py sdist register upload``
> >
> > and then give my login credentials, this happens at the end:
> >
> > ::
> >
> >    running register
> >    Password:
> >    Registering terminable_thread to http://pypi.python.org/pypi
> >    Server response (200): OK
> >    running upload
> >    Submitting dist/terminable_thread-0.7.tar.gz to
> http://pypi.python.org/pypi
> >    Upload failed (401): Incorrect password
> >
> > I get similar results if my ``~/.pypirc`` has a line in the ``[pypi]``
> section containing just ``password:``, whether or not I omit the
> ``register`` command.
> >
> > I was able to upload the distribution by putting my password in
> ``~/.pypirc``.
> >
> > The ``upload`` command seems to be checking for the password
> independently from ``register``; this runs contrary to the documentation_.
> >
> > .. _documentation:
> http://docs.python.org/distutils/packageindex.html#pypirc
> >
> > I'm running the bona fide (not ``distribute``) ``setuptools``, version
> ``0.6c11``.  This assertion is based on
> >
> > ::
> >
> >    $ cat `which easy_install` | grep load
> >    from pkg_resources import load_entry_point
> >       load_entry_point('setuptools==0.6c11', 'console_scripts',
> 'easy_install')()
> >
> > and the fact that I just deleted my old ``setuptools`` and installed by
> executing the current tarball from the ``setuptools`` PyPI page.
> >
> > ----------
> > messages: 553
> > nosy: intuited
> > priority: bug
> > status: unread
> > title: Unable to upload package without storing password in ~/.pypirc
> >
> > _______________________________________________
> > Setuptools tracker <setuptools at bugs.python.org>
> > <http://bugs.python.org/setuptools/issue117>
> > _______________________________________________
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > http://mail.python.org/mailman/listinfo/distutils-sig
> >
>
>
>
> --
> Tarek Ziad? | http://ziade.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100921/f75119f7/attachment.html>

From rlacko at gratex.com  Mon Sep 27 10:41:18 2010
From: rlacko at gratex.com (Lacko Roman)
Date: Mon, 27 Sep 2010 10:41:18 +0200
Subject: [Distutils] easy_install with post-install script
Message-ID: <A76E2EE7BA21494FB90249F8809C28B9BF7CCE7AC9@MBX.hq.gratex.com>

Hi,

Is there some way to run some post-install script when installing the python package with easy_install ?
I need to create some files in folder where the python interpreter is located.
BTW It is possible with bdist_wininst, because it support post installation scripts, but not with easy_install.

Thank in advance
Roman Lacko


From pje at telecommunity.com  Mon Sep 27 16:32:33 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 27 Sep 2010 10:32:33 -0400
Subject: [Distutils] easy_install with post-install script
In-Reply-To: <A76E2EE7BA21494FB90249F8809C28B9BF7CCE7AC9@MBX.hq.gratex.c
 om>
References: <A76E2EE7BA21494FB90249F8809C28B9BF7CCE7AC9@MBX.hq.gratex.com>
Message-ID: <20100927143230.6B56F3A4114@sparrow.telecommunity.com>

At 10:41 AM 9/27/2010 +0200, Lacko Roman wrote:
>Hi,
>
>Is there some way to run some post-install script when installing 
>the python package with easy_install ?
>I need to create some files in folder where the python interpreter is located.
>BTW It is possible with bdist_wininst, because it support post 
>installation scripts, but not with easy_install.

Add a script to your package that performs the installation step (or 
an option to an existing script), and then ask the user to run it 
after the install is complete.

(No, there's no automated way.) 


From rlacko at gratex.com  Mon Sep 27 17:05:28 2010
From: rlacko at gratex.com (Lacko Roman)
Date: Mon, 27 Sep 2010 17:05:28 +0200
Subject: [Distutils] easy_install with post-install script
In-Reply-To: <20100927143230.6B56F3A4114@sparrow.telecommunity.com>
References: <A76E2EE7BA21494FB90249F8809C28B9BF7CCE7AC9@MBX.hq.gratex.com>
	<20100927143230.6B56F3A4114@sparrow.telecommunity.com>
Message-ID: <A76E2EE7BA21494FB90249F8809C28B9BF7CCE7F00@MBX.hq.gratex.com>

Thanks for reply,

> Add a script to your package that performs the installation step (or an option
> to an existing script), and then ask the user to run it after the install is
> complete.
Yes this is how I resolved the problem before

> (No, there's no automated way.)
Do You plan to support this in future ?

Thanks
-Roman

> -----Original Message-----
> From: P.J. Eby [mailto:pje at telecommunity.com]
> Sent: Monday, September 27, 2010 4:33 PM
> To: Lacko Roman; distutils-sig at python.org
> Subject: Re: [Distutils] easy_install with post-install script
> 
> At 10:41 AM 9/27/2010 +0200, Lacko Roman wrote:
> >Hi,
> >
> >Is there some way to run some post-install script when installing the
> >python package with easy_install ?
> >I need to create some files in folder where the python interpreter is
> located.
> >BTW It is possible with bdist_wininst, because it support post
> >installation scripts, but not with easy_install.
> 
> Add a script to your package that performs the installation step (or an option
> to an existing script), and then ask the user to run it after the install is
> complete.
> 
> (No, there's no automated way.)


From pje at telecommunity.com  Mon Sep 27 18:04:22 2010
From: pje at telecommunity.com (P.J. Eby)
Date: Mon, 27 Sep 2010 12:04:22 -0400
Subject: [Distutils] easy_install with post-install script
In-Reply-To: <A76E2EE7BA21494FB90249F8809C28B9BF7CCE7F00@MBX.hq.gratex.c
 om>
References: <A76E2EE7BA21494FB90249F8809C28B9BF7CCE7AC9@MBX.hq.gratex.com>
	<20100927143230.6B56F3A4114@sparrow.telecommunity.com>
	<A76E2EE7BA21494FB90249F8809C28B9BF7CCE7F00@MBX.hq.gratex.com>
Message-ID: <20100927160413.1F6853A40F5@sparrow.telecommunity.com>

At 05:05 PM 9/27/2010 +0200, Lacko Roman wrote:
>Thanks for reply,
>
> > Add a script to your package that performs the installation step 
> (or an option
> > to an existing script), and then ask the user to run it after the 
> install is
> > complete.
>Yes this is how I resolved the problem before
>
> > (No, there's no automated way.)
>Do You plan to support this in future ?

I don't have a specific plan, but am open to finding ways to do 
it.  Those ways, however, need to allow users to know what the 
post-install operations are doing/going to do (with explicit user 
consent), along with having uninstall capabilities.


>Thanks
>-Roman
>
> > -----Original Message-----
> > From: P.J. Eby [mailto:pje at telecommunity.com]
> > Sent: Monday, September 27, 2010 4:33 PM
> > To: Lacko Roman; distutils-sig at python.org
> > Subject: Re: [Distutils] easy_install with post-install script
> >
> > At 10:41 AM 9/27/2010 +0200, Lacko Roman wrote:
> > >Hi,
> > >
> > >Is there some way to run some post-install script when installing the
> > >python package with easy_install ?
> > >I need to create some files in folder where the python interpreter is
> > located.
> > >BTW It is possible with bdist_wininst, because it support post
> > >installation scripts, but not with easy_install.
> >
> > Add a script to your package that performs the installation step 
> (or an option
> > to an existing script), and then ask the user to run it after the 
> install is
> > complete.
> >
> > (No, there's no automated way.)


From rlacko at gratex.com  Tue Sep 28 09:24:11 2010
From: rlacko at gratex.com (Lacko Roman)
Date: Tue, 28 Sep 2010 09:24:11 +0200
Subject: [Distutils] easy_install with post-install script
In-Reply-To: <20100927160413.1F6853A40F5@sparrow.telecommunity.com>
References: <A76E2EE7BA21494FB90249F8809C28B9BF7CCE7AC9@MBX.hq.gratex.com>
	<20100927143230.6B56F3A4114@sparrow.telecommunity.com>
	<A76E2EE7BA21494FB90249F8809C28B9BF7CCE7F00@MBX.hq.gratex.com>
	<20100927160413.1F6853A40F5@sparrow.telecommunity.com>
Message-ID: <A76E2EE7BA21494FB90249F8809C28B9BF7CCE80AB@MBX.hq.gratex.com>

> >
> > > Add a script to your package that performs the installation step
> > (or an option
> > > to an existing script), and then ask the user to run it after the
> > install is
> > > complete.
> >Yes this is how I resolved the problem before
> >
> > > (No, there's no automated way.)
> >Do You plan to support this in future ?
> 
> I don't have a specific plan, but am open to finding ways to do it.  Those ways,
> however, need to allow users to know what the post-install operations are
> doing/going to do (with explicit user consent), along with having uninstall
> capabilities.

I have found bdist_wininst very usefull, it has adequate support for uninstall and post-install scripts. Also pip supports package uninstallation.


> >Thanks
> >-Roman
> >
> > > -----Original Message-----
> > > From: P.J. Eby [mailto:pje at telecommunity.com]
> > > Sent: Monday, September 27, 2010 4:33 PM
> > > To: Lacko Roman; distutils-sig at python.org
> > > Subject: Re: [Distutils] easy_install with post-install script
> > >
> > > At 10:41 AM 9/27/2010 +0200, Lacko Roman wrote:
> > > >Hi,
> > > >
> > > >Is there some way to run some post-install script when installing
> > > >the python package with easy_install ?
> > > >I need to create some files in folder where the python interpreter
> > > >is
> > > located.
> > > >BTW It is possible with bdist_wininst, because it support post
> > > >installation scripts, but not with easy_install.
> > >
> > > Add a script to your package that performs the installation step
> > (or an option
> > > to an existing script), and then ask the user to run it after the
> > install is
> > > complete.
> > >
> > > (No, there's no automated way.)


From barry at python.org  Tue Sep 28 14:36:09 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 28 Sep 2010 08:36:09 -0400
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
	<20100921103424.745016d4@mission>
	<AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>
Message-ID: <20100928083609.697dba74@mission>

On Sep 25, 2010, at 09:41 PM, anatoly techtonik wrote:

>On Tue, Sep 21, 2010 at 5:34 PM, Barry Warsaw <barry at python.org> wrote:
>>
>> Yes it should definitely use doc/ if docs/ is missing.
>
>Attached patch. Review in context at
>http://codereview.appspot.com/2269042

I commented.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100928/65648236/attachment.pgp>

From barry at python.org  Tue Sep 28 15:03:53 2010
From: barry at python.org (Barry Warsaw)
Date: Tue, 28 Sep 2010 09:03:53 -0400
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTinCK-oVcrs+rTbn893XD5BCkJXMCB2VCrsui9YC@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
	<20100921103424.745016d4@mission>
	<AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>
	<AANLkTinCK-oVcrs+rTbn893XD5BCkJXMCB2VCrsui9YC@mail.gmail.com>
Message-ID: <20100928090353.0f12c077@mission>

On Sep 27, 2010, at 09:55 AM, Tarek Ziad? wrote:

>>> However, upload_docs
>>> never quite works out of the box for me anyway. ?First, it insists
>>> on an index.html file, which my Sphinx builds never seem to write,
>>> so I always have to add a symlink.
>
>Barry, do you mean that you have all files generated by Sphinx but not
>index.html ? That's weird, Sphinx should generate it like the others.

Except that I don't have an index.txt file.  It kind of doesn't make sense.  I
use buildout and have this in my buildout.cfg:

[docs]
recipe = z3c.recipe.sphinxdoc
eggs = mailman [docs]
index-doc = docs/README
default.css =
layout.html =
extensions = sphinxconf

So what I end up doing is symlinking index.html to README.html before I
upload.

>> ?Second, it doesn't seem to play nicely with the location
>>> that my buildout-based builds puts the docs, so I always also have
>>> to use --upload-dir. ?Yes, it would be nice if both of these
>>> problems were fixed too. Yes, I should report them as bugs (or just
>>> fix 'em ;).
>
>How would you fix the second issue ? e.g. if the docs is not in docs/
>or doc/

That's a good question!  Maybe it's a buildout or recipe issue?

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100928/e79d9bb7/attachment.pgp>

From techtonik at gmail.com  Wed Sep 29 10:30:08 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 29 Sep 2010 11:30:08 +0300
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTinCK-oVcrs+rTbn893XD5BCkJXMCB2VCrsui9YC@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
	<20100921103424.745016d4@mission>
	<AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>
	<AANLkTinCK-oVcrs+rTbn893XD5BCkJXMCB2VCrsui9YC@mail.gmail.com>
Message-ID: <AANLkTi=hZ=skdnAQPpG9GZ=yo5ZAQjph5p5mZMuPj356@mail.gmail.com>

On Mon, Sep 27, 2010 at 10:55 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>>>
>>> Yes it should definitely use doc/ if docs/ is missing.
>>
>> Attached patch. Review in context at http://codereview.appspot.com/2269042
>
> Thanks for the diff. Would you mind adding a tiny little test in
> test_upload_docs.test_default_uploaddir
>
> I'll be happy to merge tour change then.

Added unittest, modified version is attached and is also updated on codereview.

-- 
anatoly t.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upload_docs.doc.patch
Type: application/octet-stream
Size: 2245 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100929/e3f39004/attachment.obj>

From techtonik at gmail.com  Wed Sep 29 10:30:46 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 29 Sep 2010 11:30:46 +0300
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <20100928083609.697dba74@mission>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
	<20100921103424.745016d4@mission>
	<AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>
	<20100928083609.697dba74@mission>
Message-ID: <AANLkTinutRV+_boW8jjjNV5h=h7mUrf0tjU23HP5ZCC0@mail.gmail.com>

On Tue, Sep 28, 2010 at 3:36 PM, Barry Warsaw <barry at python.org> wrote:
>>>
>>> Yes it should definitely use doc/ if docs/ is missing.
>>
>>Attached patch. Review in context at
>>http://codereview.appspot.com/2269042
>
> I commented.

Thanks. Updated. =)
--
anatoly t.

From techtonik at gmail.com  Wed Sep 29 10:40:40 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 29 Sep 2010 11:40:40 +0300
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTi=hZ=skdnAQPpG9GZ=yo5ZAQjph5p5mZMuPj356@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
	<20100921103424.745016d4@mission>
	<AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>
	<AANLkTinCK-oVcrs+rTbn893XD5BCkJXMCB2VCrsui9YC@mail.gmail.com>
	<AANLkTi=hZ=skdnAQPpG9GZ=yo5ZAQjph5p5mZMuPj356@mail.gmail.com>
Message-ID: <AANLkTin+1BO5y7XgqVOBMG9oeuvt5Pr8+jQZgsMV-c1L@mail.gmail.com>

On Wed, Sep 29, 2010 at 11:30 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>>>>
>>>> Yes it should definitely use doc/ if docs/ is missing.
>>>
>>> Attached patch. Review in context at http://codereview.appspot.com/2269042
>>
>> Thanks for the diff. Would you mind adding a tiny little test in
>> test_upload_docs.test_default_uploaddir
>>
>> I'll be happy to merge tour change then.
>
> Added unittest, modified version is attached and is also updated on codereview.

The attached patch in this letter should be better suited for import.

-- 
anatoly t.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upload_docs.doc.patch
Type: application/octet-stream
Size: 2533 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20100929/cf66d459/attachment-0001.obj>

From ziade.tarek at gmail.com  Wed Sep 29 13:00:58 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 29 Sep 2010 13:00:58 +0200
Subject: [Distutils] docs/ vs doc/
In-Reply-To: <AANLkTin+1BO5y7XgqVOBMG9oeuvt5Pr8+jQZgsMV-c1L@mail.gmail.com>
References: <AANLkTik6rQKnH8Jc6V8FE2b2Dh-bpAoc_HouTA7t6qYM@mail.gmail.com>
	<20100921075715.632933f7@snowdog>
	<AANLkTimziP+aPmGhm8dymPXe8k3OjFUG4aKJ-fXky1yW@mail.gmail.com>
	<20100921103424.745016d4@mission>
	<AANLkTikYN6kM8Yrnh9F_mDdJcOj6YHUNif7QO+fw_GqJ@mail.gmail.com>
	<AANLkTinCK-oVcrs+rTbn893XD5BCkJXMCB2VCrsui9YC@mail.gmail.com>
	<AANLkTi=hZ=skdnAQPpG9GZ=yo5ZAQjph5p5mZMuPj356@mail.gmail.com>
	<AANLkTin+1BO5y7XgqVOBMG9oeuvt5Pr8+jQZgsMV-c1L@mail.gmail.com>
Message-ID: <AANLkTi=db1mHbNa3M2Tsk9rRsbmQbtyx1BSXZL9EMqGa@mail.gmail.com>

Pushed at http://hg.python.org/distutils2/rev/37f948f6be6c

Thanks to all !

On Wed, Sep 29, 2010 at 10:40 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Wed, Sep 29, 2010 at 11:30 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>>>>>
>>>>> Yes it should definitely use doc/ if docs/ is missing.
>>>>
>>>> Attached patch. Review in context at http://codereview.appspot.com/2269042
>>>
>>> Thanks for the diff. Would you mind adding a tiny little test in
>>> test_upload_docs.test_default_uploaddir
>>>
>>> I'll be happy to merge tour change then.
>>
>> Added unittest, modified version is attached and is also updated on codereview.
>
> The attached patch in this letter should be better suited for import.
>
> --
> anatoly t.
>



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