From lxander.m at gmail.com  Fri Aug  1 17:36:29 2008
From: lxander.m at gmail.com (Alexander Michael)
Date: Fri, 1 Aug 2008 11:36:29 -0400
Subject: [Distutils] Bug in setuptools version parsing when appending
	'.dev'?
In-Reply-To: <489101D1.3030903@enthought.com>
References: <489101D1.3030903@enthought.com>
Message-ID: <525f23e80808010836k62a1da8aka7daaca1b1320699@mail.gmail.com>

On Wed, Jul 30, 2008 at 8:05 PM, Dave Peterson <dpeterson at enthought.com> wrote:
> Am I missing something or is the following a bug whereby adding the '.dev'
> tag is doing something weird?
>
>>>> from pkg_resources import parse_requirement as pv
>>>> pv('1.0a1.dev') < pv('1.0a1')
> True
>>>> pv('1.0a1') < pv('1.0')
> True
>>>> pv('1.0a1.dev') < pv('1.0.dev')
> False
>>>> pv('1.0a1') < pv('1.0.dev')
> False
>>>> import setuptools
>>>> setuptools.__version__
> '0.6c8'
>
> This is mainly causing us problems when projects try to track alpha and beta
> level bumps in dependencies, such as when project Foo requires project Bar
> version 3.0b1 via a requirement like 'Bar >= 3.0b1' (which means we don't
> want the development prereleases of Bar's first beta release, but anything
> after that should be okay.)   But then when we actually want to release Bar
> 3.0 and change the version number to just '3.0', suddenly installs fail
> while we try to run the last set of tests because '3.0.dev' is older than
> '3.0b1'.

This looks wrong to me too. One would think that the development
version 3 (final) would be newer than any 3.beta version. But both dev
and b are pre-release tags with dev being explicitly mapped to '@' in
the parsed version so that it is treated as younger than beta:

In [2]: v('3.0.dev')
Out[2]: ('00000003', '*@', '*final')

In [3]: v('3.0b1')
Out[3]: ('00000003', '*b', '00000001', '*final')

The rationale is probably that dev releases represent "early"
development releases, while beta releases are closer to the final
release than dev releases. What I think is missing is a way of saying
(silently) that this a dev of the final, and that final is newer than
beta (and especially a dev of a beta).

> If it is not a bug, how do you handle situations where you want to run that
> last round of testing prior to tagging and building releases?  I'd rather do
> that AFTER making all source changes, and not have to change the version
> number after the testing.

To work with what we have now, I think you need to set the trunk
version to 3b2.dev (the next in-development version). And then when
you're ready for the final version of 3, bump your working copy of the
trunk to 3 (final) and do a test build with the .dev dropped (perhaps
from the command-line with python setup.py egg_info -RDb "" sdist
bdist_egg) in a virtualenv or similar sandbox where you can easily
manually wipe site-packages in case you need to iterate. Once that's
good, commit, branch and tag, release, and then immediately commit the
trunk version to 3.1.dev (3.0.1 bug-fix releases will be prepared in
the branch).

From chris at simplistix.co.uk  Sat Aug  2 17:45:34 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 02 Aug 2008 16:45:34 +0100
Subject: [Distutils] [Zope-dev] Re: bad "zope.size" to remove from PyPI
In-Reply-To: <e5fff6640808020627u68f7938fy1a60b16bf2f5f52e@mail.gmail.com>
References: <489390B2.7040905@free.fr> <48939655.8070605@weitershausen.de>
	<e5fff6640808020627u68f7938fy1a60b16bf2f5f52e@mail.gmail.com>
Message-ID: <4894811E.60808@simplistix.co.uk>

Benji York wrote:
>> In case anybody's wondering how this complies with our "no removal of any
>> release whatsoever" policy [1], be assured that a 3.4dev-r73090 thing isn't
>> a release by our standards. This version number not only contains the 'dev'
>> marker, meaning it must have come from a development branch (possibly the
>> trunk), it also contains the -rXXX suffix meaning it was made right from a
>> subversion checkout without having created a tags first (why else would you
>> want to include the revision number).
> 
> Still, it's likely that someone was using it and their buildouts are now
> broken.  We should have instead generated a proper release with a higher
> version number and left the dev release alone.

This is silly.

Mistakes happen. Buildout and/or setuptools should be tolerant of 
accidental releases that are then removed from PyPI.

What currently happens in cases like this?

cheers,

Chris

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

From philipp at weitershausen.de  Sat Aug  2 18:30:55 2008
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Sat, 2 Aug 2008 18:30:55 +0200
Subject: [Distutils] [Zope-dev] Re: bad "zope.size" to remove from PyPI
In-Reply-To: <4894811E.60808@simplistix.co.uk>
References: <489390B2.7040905@free.fr> <48939655.8070605@weitershausen.de>
	<e5fff6640808020627u68f7938fy1a60b16bf2f5f52e@mail.gmail.com>
	<4894811E.60808@simplistix.co.uk>
Message-ID: <128978C8-CD5E-48AA-8F0E-4E4B5ECC1188@weitershausen.de>

El 2 Aug 2008, a las 17:45 , Chris Withers escribi?:
> Benji York wrote:
>>> In case anybody's wondering how this complies with our "no removal  
>>> of any
>>> release whatsoever" policy [1], be assured that a 3.4dev-r73090  
>>> thing isn't
>>> a release by our standards. This version number not only contains  
>>> the 'dev'
>>> marker, meaning it must have come from a development branch  
>>> (possibly the
>>> trunk), it also contains the -rXXX suffix meaning it was made  
>>> right from a
>>> subversion checkout without having created a tags first (why else  
>>> would you
>>> want to include the revision number).
>> Still, it's likely that someone was using it and their buildouts  
>> are now
>> broken.  We should have instead generated a proper release with a  
>> higher
>> version number and left the dev release alone.
>
> This is silly.
>
> Mistakes happen. Buildout and/or setuptools should be tolerant of  
> accidental releases that are then removed from PyPI.
>
> What currently happens in cases like this?

Nothing. It's only a problem if somebody pinned zope.size version to  
3.4dev-r73090 in their buildout.cfg. But that's their own fault IMHO  
because it's clearly not a release.

From chris at simplistix.co.uk  Sun Aug  3 09:55:40 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Sun, 03 Aug 2008 08:55:40 +0100
Subject: [Distutils] what happens when the "latest" release on pypi is
	removed?
In-Reply-To: <128978C8-CD5E-48AA-8F0E-4E4B5ECC1188@weitershausen.de>
References: <489390B2.7040905@free.fr>
	<48939655.8070605@weitershausen.de>	<e5fff6640808020627u68f7938fy1a60b16bf2f5f52e@mail.gmail.com>	<4894811E.60808@simplistix.co.uk>
	<128978C8-CD5E-48AA-8F0E-4E4B5ECC1188@weitershausen.de>
Message-ID: <4895647C.3050407@simplistix.co.uk>

Philipp von Weitershausen wrote:
>> This is silly.
>>
>> Mistakes happen. Buildout and/or setuptools should be tolerant of 
>> accidental releases that are then removed from PyPI.
>>
>> What currently happens in cases like this?
> 
> Nothing. 

Well, that wouldn't be good...

In what situations would buildout or setuptools pick 3.4dev-r73090?

If it has been picked, what happens when that package is updated by 
either tool?

What *should* happen is the latest package still on pypi gets picked and 
replaces 3.4dev-r73090, maybe with a warning issued if necessary.

cheers,

Chris

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

From pje at telecommunity.com  Sun Aug  3 19:51:11 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 03 Aug 2008 13:51:11 -0400
Subject: [Distutils] Bug in setuptools version parsing when appending
 '.dev'?
In-Reply-To: <489101D1.3030903@enthought.com>
References: <489101D1.3030903@enthought.com>
Message-ID: <20080803175021.9E9543A4093@sparrow.telecommunity.com>

At 07:05 PM 7/30/2008 -0500, Dave Peterson wrote:
>Am I missing something or is the following a bug whereby adding the 
>'.dev' tag is doing something weird?
>
> >>> from pkg_resources import parse_requirement as pv
> >>> pv('1.0a1.dev') < pv('1.0a1')
>True
> >>> pv('1.0a1') < pv('1.0')
>True
> >>> pv('1.0a1.dev') < pv('1.0.dev')
>False
> >>> pv('1.0a1') < pv('1.0.dev')
>False
> >>> import setuptools
> >>> setuptools.__version__
>'0.6c8'
>
>This is mainly causing us problems when projects try to track alpha 
>and beta level bumps in dependencies, such as when project Foo 
>requires project Bar version 3.0b1 via a requirement like 'Bar >= 
>3.0b1' (which means we don't want the development prereleases of 
>Bar's first beta release, but anything after that should be 
>okay.)   But then when we actually want to release Bar 3.0 and 
>change the version number to just '3.0', suddenly installs fail 
>while we try to run the last set of tests because '3.0.dev' is older 
>than '3.0b1'.
>
>If it is not a bug, how do you handle situations where you want to 
>run that last round of testing prior to tagging and building 
>releases?  I'd rather do that AFTER making all source changes, and 
>not have to change the version number after the testing.

This is what 'rc' tags are for, actually.  You can put your version 
in the source, and use the -b option to egg_info while doing builds 
and testing to tack on an 'rc' tag, possibly with a subversion number as well.


From dpeterson at enthought.com  Mon Aug  4 19:02:01 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Mon, 04 Aug 2008 12:02:01 -0500
Subject: [Distutils] Bug in setuptools version parsing when appending
 '.dev'?
In-Reply-To: <20080803175021.9E9543A4093@sparrow.telecommunity.com>
References: <489101D1.3030903@enthought.com>
	<20080803175021.9E9543A4093@sparrow.telecommunity.com>
Message-ID: <48973609.9030609@enthought.com>

Phillip J. Eby wrote:
> At 07:05 PM 7/30/2008 -0500, Dave Peterson wrote:
>> Am I missing something or is the following a bug whereby adding the 
>> '.dev' tag is doing something weird?
>>
>> >>> from pkg_resources import parse_requirement as pv
>> >>> pv('1.0a1.dev') < pv('1.0a1')
>> True
>> >>> pv('1.0a1') < pv('1.0')
>> True
>> >>> pv('1.0a1.dev') < pv('1.0.dev')
>> False
>> >>> pv('1.0a1') < pv('1.0.dev')
>> False
>> >>> import setuptools
>> >>> setuptools.__version__
>> '0.6c8'
>>
>> This is mainly causing us problems when projects try to track alpha 
>> and beta level bumps in dependencies, such as when project Foo 
>> requires project Bar version 3.0b1 via a requirement like 'Bar >= 
>> 3.0b1' (which means we don't want the development prereleases of 
>> Bar's first beta release, but anything after that should be okay.)   
>> But then when we actually want to release Bar 3.0 and change the 
>> version number to just '3.0', suddenly installs fail while we try to 
>> run the last set of tests because '3.0.dev' is older than '3.0b1'.
>>
>> If it is not a bug, how do you handle situations where you want to 
>> run that last round of testing prior to tagging and building 
>> releases?  I'd rather do that AFTER making all source changes, and 
>> not have to change the version number after the testing.
>
> This is what 'rc' tags are for, actually.  You can put your version in 
> the source, and use the -b option to egg_info while doing builds and 
> testing to tack on an 'rc' tag, possibly with a subversion number as 
> well.

Perhaps I'm missing something, but that doesn't seem like it scales to a 
community -- not everyone is going to remember to use a '-b' option when 
building and that is going to cause endless support problems.   We do 
put the following in our setup.cfg so that people don't mistakenly build 
release versions when not intending to do so:

[egg_info]
tag_build = .dev
tag_svn_revision = 1

Are you staying the standard process for setuptools is to delete / 
modify this when tagging a release in the repo?  If not, how do you 
avoid the problem of someone building from a source checkout and finding 
out that 3.0.dev-r1234 doesn't satisfy the '>= 3.0b1' dependency spec?


-- Dave



From dpeterson at enthought.com  Mon Aug  4 19:24:58 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Mon, 04 Aug 2008 12:24:58 -0500
Subject: [Distutils] Bug in setuptools version parsing when appending
 '.dev'?
In-Reply-To: <525f23e80808010836k62a1da8aka7daaca1b1320699@mail.gmail.com>
References: <489101D1.3030903@enthought.com>
	<525f23e80808010836k62a1da8aka7daaca1b1320699@mail.gmail.com>
Message-ID: <48973B6A.2010908@enthought.com>

Alexander Michael wrote:
> On Wed, Jul 30, 2008 at 8:05 PM, Dave Peterson <dpeterson at enthought.com> wrote:
>   
>> Am I missing something or is the following a bug whereby adding the '.dev'
>> tag is doing something weird?
>>
>>     
>>>>> from pkg_resources import parse_requirement as pv
>>>>> pv('1.0a1.dev') < pv('1.0a1')
>>>>>           
>> True
>>     
>>>>> pv('1.0a1') < pv('1.0')
>>>>>           
>> True
>>     
>>>>> pv('1.0a1.dev') < pv('1.0.dev')
>>>>>           
>> False
>>     
>>>>> pv('1.0a1') < pv('1.0.dev')
>>>>>           
>> False
>>     
>>>>> import setuptools
>>>>> setuptools.__version__
>>>>>           
>> '0.6c8'
>>
>> This is mainly causing us problems when projects try to track alpha and beta
>> level bumps in dependencies, such as when project Foo requires project Bar
>> version 3.0b1 via a requirement like 'Bar >= 3.0b1' (which means we don't
>> want the development prereleases of Bar's first beta release, but anything
>> after that should be okay.)   But then when we actually want to release Bar
>> 3.0 and change the version number to just '3.0', suddenly installs fail
>> while we try to run the last set of tests because '3.0.dev' is older than
>> '3.0b1'.
>>     
>
> This looks wrong to me too. One would think that the development
> version 3 (final) would be newer than any 3.beta version. But both dev
> and b are pre-release tags with dev being explicitly mapped to '@' in
> the parsed version so that it is treated as younger than beta:
>
> In [2]: v('3.0.dev')
> Out[2]: ('00000003', '*@', '*final')
>
> In [3]: v('3.0b1')
> Out[3]: ('00000003', '*b', '00000001', '*final')
>
> The rationale is probably that dev releases represent "early"
> development releases, while beta releases are closer to the final
> release than dev releases. What I think is missing is a way of saying
> (silently) that this a dev of the final, and that final is newer than
> beta (and especially a dev of a beta).
>   

Actually, you can append the tag 'final' and it seems to work fine:

 >>> pv('3.0.final.dev') > pv(3.0b1')
True

I just hate to add the tag 'final' to a final release due to the extra 
typing it causes people.   It seems to me the community expectation is 
to be able to do things like "easy_install Traits==3.0"  rather than 
"easy_install Traits==3.0.final"


>> If it is not a bug, how do you handle situations where you want to run that
>> last round of testing prior to tagging and building releases?  I'd rather do
>> that AFTER making all source changes, and not have to change the version
>> number after the testing.
>>     
>
> To work with what we have now, I think you need to set the trunk
> version to 3b2.dev (the next in-development version). And then when
> you're ready for the final version of 3, bump your working copy of the
> trunk to 3 (final) and do a test build with the .dev dropped (perhaps
> from the command-line with python setup.py egg_info -RDb "" sdist
> bdist_egg) in a virtualenv or similar sandbox where you can easily
> manually wipe site-packages in case you need to iterate. Once that's
> good, commit, branch and tag, release, and then immediately commit the
> trunk version to 3.1.dev (3.0.1 bug-fix releases will be prepared in
> the branch).
>   

The problem here is that we *released* Traits 3.0.  It is no longer a 
beta.  But other projects that wanted to rely on it as soon as it was in 
a stable beta put in a requirement of "Traits >=3.0b1".  Unfortunately, 
if developers check-out the tag of the release and do a build, they get 
Traits with version "3.0.dev-rXXXXX' which setuptools says doesn't 
satisfy "Traits >=3.0b1".    They get the '.dev' because we have 
historically not modified the source's setup.cfg when tagging the 
release (we do NO changes between the last build/test cycle and the 
tagging.)


-- Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080804/7a115753/attachment.htm>

From lxander.m at gmail.com  Mon Aug  4 19:41:19 2008
From: lxander.m at gmail.com (Alexander Michael)
Date: Mon, 4 Aug 2008 13:41:19 -0400
Subject: [Distutils] Bug in setuptools version parsing when appending
	'.dev'?
In-Reply-To: <48973B6A.2010908@enthought.com>
References: <489101D1.3030903@enthought.com>
	<525f23e80808010836k62a1da8aka7daaca1b1320699@mail.gmail.com>
	<48973B6A.2010908@enthought.com>
Message-ID: <525f23e80808041041q1031c449i2b50cc5762e769ad@mail.gmail.com>

On Mon, Aug 4, 2008 at 1:24 PM, Dave Peterson <dpeterson at enthought.com> wrote:
> Alexander Michael wrote:
>> The rationale is probably that dev releases represent "early"
>> development releases, while beta releases are closer to the final
>> release than dev releases. What I think is missing is a way of saying
>> (silently) that this a dev of the final, and that final is newer than
>> beta (and especially a dev of a beta).
>
> Actually, you can append the tag 'final' and it seems to work fine:
>
>>>> pv('3.0.final.dev') > pv(3.0b1')
> True
>
> I just hate to add the tag 'final' to a final release due to the extra
> typing it causes people.   It seems to me the community expectation is to be
> able to do things like "easy_install Traits==3.0"  rather than "easy_install
> Traits==3.0.final"

I thought this might work, which is why I suggested that maybe it
could be done "silently". For example, in the setup.py files but not
at the easy_install command-line. This implicit complication would
probably lead to other wonkiness though...

>> To work with what we have now, I think you need to set the trunk
>> version to 3b2.dev (the next in-development version). And then when
>> you're ready for the final version of 3, bump your working copy of the
>> trunk to 3 (final) and do a test build with the .dev dropped (perhaps
>> from the command-line with python setup.py egg_info -RDb "" sdist
>> bdist_egg) in a virtualenv or similar sandbox where you can easily
>> manually wipe site-packages in case you need to iterate. Once that's
>> good, commit, branch and tag, release, and then immediately commit the
>> trunk version to 3.1.dev (3.0.1 bug-fix releases will be prepared in
>> the branch).
>
> The problem here is that we *released* Traits 3.0.  It is no longer a beta.
> But other projects that wanted to rely on it as soon as it was in a stable
> beta put in a requirement of "Traits >=3.0b1".  Unfortunately, if developers
> check-out the tag of the release and do a build, they get Traits with
> version "3.0.dev-rXXXXX' which setuptools says doesn't satisfy "Traits
>>=3.0b1".    They get the '.dev' because we have historically not modified
> the source's setup.cfg when tagging the release (we do NO changes between
> the last build/test cycle and the tagging.)

Again, attempting to offer up practical solutions. Edit the
setup.cfg's to drop the dev option in the release branches and update
the trunk to the next version (i.e. 3.1.dev-rXXXXX)? That way,
checkouts of the release branches will be 3.0-rXXXXX (a post release
of 3) and the trunk will be a post of a pre-release that is newer than
anything else in the repository. Just a thought...

Regards,
Alex

P.S. And serious congrats on the Traits release-- Traits rocks!

From pje at telecommunity.com  Tue Aug  5 00:32:07 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 04 Aug 2008 18:32:07 -0400
Subject: [Distutils] Bug in setuptools version parsing when appending
 '.dev'?
In-Reply-To: <48973609.9030609@enthought.com>
References: <489101D1.3030903@enthought.com>
	<20080803175021.9E9543A4093@sparrow.telecommunity.com>
	<48973609.9030609@enthought.com>
Message-ID: <20080804223119.AA9EB3A4093@sparrow.telecommunity.com>

At 12:02 PM 8/4/2008 -0500, Dave Peterson wrote:
>Phillip J. Eby wrote:
>>At 07:05 PM 7/30/2008 -0500, Dave Peterson wrote:
>>>Am I missing something or is the following a bug whereby adding 
>>>the '.dev' tag is doing something weird?
>>>
>>> >>> from pkg_resources import parse_requirement as pv
>>> >>> pv('1.0a1.dev') < pv('1.0a1')
>>>True
>>> >>> pv('1.0a1') < pv('1.0')
>>>True
>>> >>> pv('1.0a1.dev') < pv('1.0.dev')
>>>False
>>> >>> pv('1.0a1') < pv('1.0.dev')
>>>False
>>> >>> import setuptools
>>> >>> setuptools.__version__
>>>'0.6c8'
>>>
>>>This is mainly causing us problems when projects try to track 
>>>alpha and beta level bumps in dependencies, such as when project 
>>>Foo requires project Bar version 3.0b1 via a requirement like 
>>>'Bar >= 3.0b1' (which means we don't want the development 
>>>prereleases of Bar's first beta release, but anything after that 
>>>should be okay.)
>>>But then when we actually want to release Bar 3.0 and change the 
>>>version number to just '3.0', suddenly installs fail while we try 
>>>to run the last set of tests because '3.0.dev' is older than '3.0b1'.
>>>
>>>If it is not a bug, how do you handle situations where you want to 
>>>run that last round of testing prior to tagging and building 
>>>releases?  I'd rather do that AFTER making all source changes, and 
>>>not have to change the version number after the testing.
>>
>>This is what 'rc' tags are for, actually.  You can put your version 
>>in the source, and use the -b option to egg_info while doing builds 
>>and testing to tack on an 'rc' tag, possibly with a subversion number as well.
>
>Perhaps I'm missing something, but that doesn't seem like it scales 
>to a community -- not everyone is going to remember to use a '-b' 
>option when building and that is going to cause endless support problems.

Only the creator of a release uses that; the community should never 
be building "release" versions.


>    We do put the following in our setup.cfg so that people don't 
> mistakenly build release versions when not intending to do so:
>
>[egg_info]
>tag_build = .dev
>tag_svn_revision = 1
>
>Are you staying the standard process for setuptools is to delete / 
>modify this when tagging a release in the repo?

I personally don't tag releases in the repository; a release is not a 
tag.  I have an alias called 'release' that maps to 'egg_info -Rdb 
""', and I use it when issuing release builds.

However, there's nothing stopping you from creating a utility that 
copies the trunk to a tag, checks out the tag, removes the options, 
and checks in the tag, if that would be your preferred approach.


>   If not, how do you avoid the problem of someone building from a 
> source checkout and finding out that 3.0.dev-r1234 doesn't satisfy 
> the '>= 3.0b1' dependency spec?

I bump the version number in SVN immediately after making a release, 
so that the trunk would be '3.1.dev-r1234', not '3.0dev'.  If you're 
using .dev tags in your egg-info setup, you should bump the version 
in setup.py immediately *after* releasing, to avoid just this situation.


From pje at telecommunity.com  Tue Aug  5 00:39:21 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 04 Aug 2008 18:39:21 -0400
Subject: [Distutils] Bug in setuptools version parsing when appending
 '.dev'?
In-Reply-To: <525f23e80808041041q1031c449i2b50cc5762e769ad@mail.gmail.co
 m>
References: <489101D1.3030903@enthought.com>
	<525f23e80808010836k62a1da8aka7daaca1b1320699@mail.gmail.com>
	<48973B6A.2010908@enthought.com>
	<525f23e80808041041q1031c449i2b50cc5762e769ad@mail.gmail.com>
Message-ID: <20080804223831.E8C093A40D9@sparrow.telecommunity.com>

At 01:41 PM 8/4/2008 -0400, Alexander Michael wrote:
>Again, attempting to offer up practical solutions. Edit the
>setup.cfg's to drop the dev option in the release branches and update
>the trunk to the next version (i.e. 3.1.dev-rXXXXX)? That way,
>checkouts of the release branches will be 3.0-rXXXXX (a post release
>of 3) and the trunk will be a post of a pre-release that is newer than
>anything else in the repository. Just a thought...

This is basically what I do, except I don't bother having release 
branches or tags, and instead of editing the setup.cfg, I just use my 
"release" alias (which maps to 'egg_info -RDb""').

So, when I did two back-to-back releases of BytecodeAssembler today 
(due to finding a bug after the first release), my command sequence was:

    # start: version in setup.py is 0.4, release on Pypi is 0.3

    # do development of version 0.4 w/periodic checkins
    setup.py wikiup   # upload wiki pages
    setup.py release sdist bdist_egg upload
    # ... edit version number from 0.4 to 0.5 and check in

    # ... find bug, fix it, check it in
    setup.py wikiup   # upload wiki pages
    setup.py release sdist bdist_egg upload
    # ... edit version number from 0.5 to 0.6 and check in

    # end: version in setup.py is 0.6, release on Pypi is 0.5

Of course, a more robust procedure would probably be to use x.1 
versions (e.g. 0.4.1 instead of 0.5), and then bump to the next 
non-bugfix version number when development begins on the next 
release.  If you have release branches, then I guess you'd do the 
bugfix bump on the branch, and a non-bugfix increment on the trunk.


From chris at simplistix.co.uk  Tue Aug  5 12:06:25 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 05 Aug 2008 11:06:25 +0100
Subject: [Distutils] [buildout] weird behaviour of first buildout on
	windows...
Message-ID: <48982621.6010802@simplistix.co.uk>

Hi All,

Looks like something weird is happening:

C:\aproject\trunk>python bootstrap.py
<snip>
C:\aproject\trunk>bin\buildout.exe
Getting distribution for 'zc.buildout'.
Getting distribution for 'setuptools'.
Got setuptools 0.6c8.
Got zc.buildout 1.1.1.

C:\aproject\trunk>Upgraded:
   zc.buildout version 1.1.1,
   setuptools version 0.6c8;
restarting.

At this point here, it looks like buildout is running in some kind of 
backgrounded process, which means that:

- if I hit enter while it's still progressing, I get things like:

"""
Getting distribution for 'zope.testing'.

C:\aproject\trunk>
C:\aproject\trunk>
C:\aproject\trunk>Got zope.testing 3.6.0.
bin\                   bin\buildout.exeGetting distribution for 
'zope.interface'
.                                                               Got 
zope.interfa
"""

- I don't know when buildout is finished because the command prompt was 
echoed way back in the middle of things.

NB: This only appears to happen the first time setuptools and buildout 
are installed. Further run of bin\buildout don't exhibit this behaviour.

cheers,

Chris

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

From ianb at colorstudy.com  Tue Aug  5 18:07:46 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 05 Aug 2008 11:07:46 -0500
Subject: [Distutils] [ANN] EggFreezer
In-Reply-To: <489878B0.20304@toscat.net>
References: <48983A0E.5090902@toscat.net> <489872F2.4090305@colorstudy.com>
	<489878B0.20304@toscat.net>
Message-ID: <48987AD2.7000205@colorstudy.com>

Alberto Valverde wrote:
> Ian Bicking wrote:
>> Alberto Valverde wrote:
>>   
>>> The usage is pretty straightforward:
>>>
>>> eggfreezer -o AllTurbogears2 -f
>>> http://turbogears.org/2.0/downloads/current TurboGears2 tg.devtools
>>>
>>> That command will try to satisfy all dependencies for TurboGears2 and
>>> tg.devtools (fetching them from local packages if available), using that
>>> url to find links, and bundle them into a file called
>>> AllTurboGears2-${py_version}-${platform}.py.
>>>     
>> As long as you are doing platforms, it might be nice to get them right. 
>>   Specifically the UCS2/UCS4 distinction, though there might be more 
>> that I'm forgetting.  (If there's actually platform-dependent files in 
>> there, if not it'd be nice to leave out the platform entirely.)
>>   
> I'm using pkg_resources.Distribution's 'platform' attribute to get this,
> the algorithm basically iterates over all dependencies and as soon as
> one has it set to not None it'll use that. If all are set to None then
> no ${platform} is added to the filename. I'm assuming of course that all
> distributions have the same string as platform, which I guess it isn't
> not too far-fetched, but haven't really checked so I'm sure there's
> something I might have overlooked.
> 
> BTW, does pkg_resources populate it properly with he UCS2/UCS4
> distinction you mention?

No... which makes binary eggs unusable on Linux.  I feel like there was 
something else that made binary packages on a Mac unreliable, but I 
can't remember.  Windows binary eggs generally work fine.  This is 
discussed some here: 
http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/

One nuisance is that people don't generally know how their Python was 
built (UCS2 or UCS4).  I was thinking about making something very 
similar to eggfreezer (which I'm unlikely to do now that eggfreezer 
exists ;), and generating an "install" .py file that determines the 
platform and downloads the appropriate platform bundle.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From alberto at toscat.net  Tue Aug  5 18:48:49 2008
From: alberto at toscat.net (Alberto Valverde)
Date: Tue, 05 Aug 2008 18:48:49 +0200
Subject: [Distutils] [tg-trunk] Re: [ANN] EggFreezer
In-Reply-To: <48987AD2.7000205@colorstudy.com>
References: <48983A0E.5090902@toscat.net> <489872F2.4090305@colorstudy.com>
	<489878B0.20304@toscat.net> <48987AD2.7000205@colorstudy.com>
Message-ID: <48988471.8020703@toscat.net>

Ian Bicking wrote:
> Alberto Valverde wrote:
>   
>> Ian Bicking wrote:
>>     
>>> Alberto Valverde wrote:
>>>   
>>>       
>>>> The usage is pretty straightforward:
>>>>
>>>> eggfreezer -o AllTurbogears2 -f
>>>> http://turbogears.org/2.0/downloads/current TurboGears2 tg.devtools
>>>>
>>>> That command will try to satisfy all dependencies for TurboGears2 and
>>>> tg.devtools (fetching them from local packages if available), using that
>>>> url to find links, and bundle them into a file called
>>>> AllTurboGears2-${py_version}-${platform}.py.
>>>>     
>>>>         
>>> As long as you are doing platforms, it might be nice to get them right. 
>>>   Specifically the UCS2/UCS4 distinction, though there might be more 
>>> that I'm forgetting.  (If there's actually platform-dependent files in 
>>> there, if not it'd be nice to leave out the platform entirely.)
>>>   
>>>       
>> I'm using pkg_resources.Distribution's 'platform' attribute to get this,
>> the algorithm basically iterates over all dependencies and as soon as
>> one has it set to not None it'll use that. If all are set to None then
>> no ${platform} is added to the filename. I'm assuming of course that all
>> distributions have the same string as platform, which I guess it isn't
>> not too far-fetched, but haven't really checked so I'm sure there's
>> something I might have overlooked.
>>
>> BTW, does pkg_resources populate it properly with he UCS2/UCS4
>> distinction you mention?
>>     
>
> No... which makes binary eggs unusable on Linux.  I feel like there was 
> something else that made binary packages on a Mac unreliable, but I 
> can't remember.  Windows binary eggs generally work fine.  This is 
> discussed some here: 
> http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/
>   

I remember reading that... Perhaps a solution could be to"freeze" the
tar.gzs too, beside the compiled eggs in case we're lucky,  and hope
that a compiler + libs are there when the install script is thawed. If
the compiled egg won't cut it, then try to compile form source. I'm not
sure how to tell easy_install to download the source distributions though.
> One nuisance is that people don't generally know how their Python was 
> built (UCS2 or UCS4).  I was thinking about making something very 
> similar to eggfreezer (which I'm unlikely to do now that eggfreezer 
> exists ;),
You're patches are welcomed, In fact, If you want to include it inside
virtualenv I would be most happy :).

>  and generating an "install" .py file that determines the 
> platform and downloads the appropriate platform bundle.
>   

Hmm, this "download" is precisely what I'm trying to avoid. My main use
case is: A machine has gone down and I want to quickly put back
everything together in another machine with a backup and something that
contains *all* needed software. Sort of like an apt reposisory inside a
dvd which lets you install debian on a machine with absolutely not net
access. The "no-net" condition is just there to guarantee that all deps
will be available no matter how old and discontinued they are (which if
I think about it is rather ambitious... well, at least make it more
likely than with the current situation)

I think that this multi-platform issue could be solved by bundling all
the different binary versions of all binary packages. However, I'm not
sure if pkg_resources could deal with the UCS2/UCS4 issue given that it
doesn't distinguish it in the platform id. Maybe by hacking in an extra
placeholder, before the .egg and after the ${platform}, that the script
uses to distinguish and then remove it before giving it to easy_install?
Though this smells like the root of the problem comes from setuptools
and should be fixed there...

Alberto

From ianb at colorstudy.com  Tue Aug  5 21:17:21 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 05 Aug 2008 14:17:21 -0500
Subject: [Distutils] [tg-trunk] Re: [ANN] EggFreezer
In-Reply-To: <48988471.8020703@toscat.net>
References: <48983A0E.5090902@toscat.net> <489872F2.4090305@colorstudy.com>
	<489878B0.20304@toscat.net> <48987AD2.7000205@colorstudy.com>
	<48988471.8020703@toscat.net>
Message-ID: <4898A741.3070201@colorstudy.com>

Alberto Valverde wrote:
[...]
>> No... which makes binary eggs unusable on Linux.  I feel like there was 
>> something else that made binary packages on a Mac unreliable, but I 
>> can't remember.  Windows binary eggs generally work fine.  This is 
>> discussed some here: 
>> http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/
>>   
> 
> I remember reading that... Perhaps a solution could be to"freeze" the
> tar.gzs too, beside the compiled eggs in case we're lucky,  and hope
> that a compiler + libs are there when the install script is thawed. If
> the compiled egg won't cut it, then try to compile form source. I'm not
> sure how to tell easy_install to download the source distributions though.

Well, it'll make eggs from your tarballs anyway.  Turning it into a 
build process is a bit of a nuisance... I was hoping for something that 
didn't require building, but just did installation.

That said, it might work.  Maybe PoachEggs (mentioned later) does what 
you want in this case.  Or, maybe it can be slightly modified to do what 
you want (I think it might also unintentionally turn tarballs into eggs).

>> One nuisance is that people don't generally know how their Python was 
>> built (UCS2 or UCS4).  I was thinking about making something very 
>> similar to eggfreezer (which I'm unlikely to do now that eggfreezer 
>> exists ;),
> You're patches are welcomed, In fact, If you want to include it inside
> virtualenv I would be most happy :).

Not so much virtualenv, but it might fit in PoachEggs: 
https://svn.openplans.org/svn/PoachEggs/trunk

workingenv did installation, but I abandoned that when I cleaned it up 
as virtualenv, and now I'm inclined to keep them separate (though 
clearly complementary).

I have thought about putting something in virtualenv to make relocating 
the environment easier.  There's only a few things that need to be 
modified, I think.  That might mitigate some of these issues.

>>  and generating an "install" .py file that determines the 
>> platform and downloads the appropriate platform bundle.
>>   
> 
> Hmm, this "download" is precisely what I'm trying to avoid. My main use
> case is: A machine has gone down and I want to quickly put back
> everything together in another machine with a backup and something that
> contains *all* needed software. Sort of like an apt reposisory inside a
> dvd which lets you install debian on a machine with absolutely not net
> access. The "no-net" condition is just there to guarantee that all deps
> will be available no matter how old and discontinued they are (which if
> I think about it is rather ambitious... well, at least make it more
> likely than with the current situation)

With PoachEggs I've now got it working so you can build a working 
environment, create a "requirements" file that lists everything in that 
working environment, download all the eggs for that into a directory, 
and then later install from that directory and disallow network access. 
  Well, more-or-less.  It's not a single-file install like eggfreezer, 
but they are working toward similar goals.

The single-file install including binaries is something I would really 
like for Deliverance, and specifically for lxml, but also to create a 
simple installation experience for people who don't know anything about 
Python build things (and maybe don't know Python).

> I think that this multi-platform issue could be solved by bundling all
> the different binary versions of all binary packages. However, I'm not
> sure if pkg_resources could deal with the UCS2/UCS4 issue given that it
> doesn't distinguish it in the platform id. Maybe by hacking in an extra
> placeholder, before the .egg and after the ${platform}, that the script
> uses to distinguish and then remove it before giving it to easy_install?
> Though this smells like the root of the problem comes from setuptools
> and should be fixed there...

If you could select the appropriate binary at installation time you 
could include all of them in the bundle.  It would be big, but at least 
personally that would be fine for me.  It would be simpler to simply 
name the resulting file with a more accurate platform, but then people 
don't always know the right thing to get.  At least a little check in 
the script itself would be helpful, so they get errors immediately 
instead of confusing errors at import time.  I'm not sure how to detect 
UCS2/UCS4.

The root (well, *one* root) of the problem is setuptools/distutils not 
getting the platform really right, but there's also all kinds of messy 
backward compatibility issues there, and no backward compatibility 
issues for eggfreezer.  I'm not sure there aren't other issues.  I'm 
also not sure that there isn't a finite number of resolvable issues.  So 
maybe MacPorts and fink and system python on Macs are different.  But 
that's just 3 platforms instead of 1, it's not an infinite number.  And 
UCS2 Python is different from UCS4 on Linux, but that's really the one 
issue I know of where Linux Pythons differ.  In theory other differences 
could occur, but in practice there's maybe 10 platforms instead of 3, 
and that's not unreasonable.

Reading a comment on the philikon article 
(http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/#comment-47), 
I also notice that Enthought has done some work on this, it seems by 
fixing up the binary packages at install time.  This seems to be related 
to an entirely different issue of the location of libraries and binary 
incompatibilities, which I only slightly understand.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From setuptools at bugs.python.org  Wed Aug  6 01:28:23 2008
From: setuptools at bugs.python.org (Dave Peterson)
Date: Tue, 05 Aug 2008 23:28:23 +0000
Subject: [Distutils] [issue30] [PATCH] ability to upload a pre-built egg to
	PyPi
In-Reply-To: <1217978903.33.0.778552974213.issue30@psf.upfronthosting.co.za>
Message-ID: <1217978903.33.0.778552974213.issue30@psf.upfronthosting.co.za>


New submission from Dave Peterson <dpeterson at enthought.com>:

It would be convenient to be able to upload pre-built eggs using the 'python
setup.py upload' command as the owner/author of a project may not have machines
available to cover the platforms for which pre-built binaries are desired. 
Having this feature would allow the project owner / maintainer to accept
pre-built eggs from others in their project community and get them onto PyPi.

I've put together and attached a patch that adds a new '--bdist-path' (or '-b')
option to the upload command that allows calls like 'python setup.py upload -b
dist/foo-1.0-py2.5-win32.egg' to work.

The patch is actually for the distutils.command.upload module as I've found that
in setuptools-0.6c8, even though there is a setuptools/command/upload module, it
isn't used at all.  I'm assuming this is because there isn't much difference
between the setuptools and distutils versions of this command but that something
was intended eventually.  I'm making this a setuptools ticket because I'd like
to see this improvement in setuptools :-)

----------
files: upload.py.patch
messages: 77
nosy: dpeterson
priority: feature
status: unread
title: [PATCH] ability to upload a pre-built egg to PyPi
Added file: http://bugs.python.org/setuptools/file11/upload.py.patch

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue30>
_______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upload.py.patch
Type: text/x-diff
Size: 1723 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080805/15694a75/attachment.patch>

From chris.arndt at web.de  Wed Aug  6 02:24:00 2008
From: chris.arndt at web.de (Christopher Arndt)
Date: Wed, 06 Aug 2008 02:24:00 +0200
Subject: [Distutils] [ANN] EggFreezer
In-Reply-To: <48987AD2.7000205@colorstudy.com>
References: <48983A0E.5090902@toscat.net> <489872F2.4090305@colorstudy.com>
	<489878B0.20304@toscat.net> <48987AD2.7000205@colorstudy.com>
Message-ID: <4898EF20.6040402@web.de>

Ian Bicking schrieb:
> No... which makes binary eggs unusable on Linux.  I feel like there was 
> something else that made binary packages on a Mac unreliable, but I 
> can't remember.

For example that fat eggs (i.e. those with binary code for intel and ppc 
architecture inlcuded) will not work on Leopard 10.5?

Chris

From chris.arndt at web.de  Wed Aug  6 02:24:00 2008
From: chris.arndt at web.de (Christopher Arndt)
Date: Wed, 06 Aug 2008 02:24:00 +0200
Subject: [Distutils] [ANN] EggFreezer
In-Reply-To: <48987AD2.7000205@colorstudy.com>
References: <48983A0E.5090902@toscat.net> <489872F2.4090305@colorstudy.com>
	<489878B0.20304@toscat.net> <48987AD2.7000205@colorstudy.com>
Message-ID: <4898EF20.6040402@web.de>

Ian Bicking schrieb:
> No... which makes binary eggs unusable on Linux.  I feel like there was 
> something else that made binary packages on a Mac unreliable, but I 
> can't remember.

For example that fat eggs (i.e. those with binary code for intel and ppc 
architecture inlcuded) will not work on Leopard 10.5?

Chris


From limi at plone.org  Wed Aug  6 05:46:00 2008
From: limi at plone.org (Alexander Limi)
Date: Tue, 5 Aug 2008 20:46:00 -0700 (PDT)
Subject: [Distutils] A release to at least stop crashing on Subversion
 1.5 would be nice
In-Reply-To: <494F0521440A5B4CBFE04D8A570B9F23014E47C84A@bt-exchange.BlueTech.local>
References: <494F0521440A5B4CBFE04D8A570B9F23014E47C84A@bt-exchange.BlueTech.local>
Message-ID: <18843787.post@talk.nabble.com>



Arlo Belshee wrote:
> 
> Also, since setuptools was likely installed automatically for him via the
> egg in the cheeseshop, he isn't aware of anything that may be in dev for
> setuptools. A new user's likely response is to get frustrated for 15
> minutes, then move on to another web framework / language.
> 

Seconded. We are feeling this pain in the Plone project too. Is there
anything we can do to speed up the release of a version that doesn't break
with Subversion 1.5?


-- 
View this message in context: http://www.nabble.com/A-release-to-at-least-stop-crashing-on-Subversion-1.5-would-be-nice-tp18636917p18843787.html
Sent from the Python - distutils-sig mailing list archive at Nabble.com.


From setuptools at bugs.python.org  Wed Aug  6 08:42:38 2008
From: setuptools at bugs.python.org (Philip Jenvey)
Date: Wed, 06 Aug 2008 06:42:38 +0000
Subject: [Distutils] [issue31] [PATCH] Skip failing tests on Jython
In-Reply-To: <1218004957.95.0.809451462777.issue31@psf.upfronthosting.co.za>
Message-ID: <1218004957.95.0.809451462777.issue31@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at underboss.org>:

(Extracted from #9)

This patch disables failing tests on Jython. Per our last conversation on 
distutils-sig about the failing functionality -- it isn't actually being used, 
anyway

----------
assignedto: pje
files: jython_failures-r65223.diff
messages: 79
nosy: pje, pjenvey
priority: bug
status: unread
title: [PATCH] Skip failing tests on Jython
Added file: http://bugs.python.org/setuptools/file13/jython_failures-r65223.diff

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue31>
_______________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jython_failures-r65223.diff
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080806/7164c2dc/attachment.txt>

From chris at simplistix.co.uk  Wed Aug  6 19:14:13 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 06 Aug 2008 18:14:13 +0100
Subject: [Distutils] [buildout] where does the demo egg come from in tests?
Message-ID: <4899DBE5.3080400@simplistix.co.uk>

Hi All,

I'm reading http://pypi.python.org/pypi/zc.recipe.egg#script-generation 
with a hope to finding out how to write an egg such that I can have mroe 
own scripts generated and called.

I think having a read of the demo egg used in these tests would solve my 
problems, but where does it live?

cheers,

Chris

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

From dpeterson at enthought.com  Wed Aug  6 19:15:30 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Wed, 06 Aug 2008 12:15:30 -0500
Subject: [Distutils] Bug in setuptools version parsing when appending
 '.dev'?
In-Reply-To: <20080804223119.AA9EB3A4093@sparrow.telecommunity.com>
References: <489101D1.3030903@enthought.com>
	<20080803175021.9E9543A4093@sparrow.telecommunity.com>
	<48973609.9030609@enthought.com>
	<20080804223119.AA9EB3A4093@sparrow.telecommunity.com>
Message-ID: <4899DC32.6070801@enthought.com>

Phillip J. Eby wrote:
> At 12:02 PM 8/4/2008 -0500, Dave Peterson wrote:
>> Phillip J. Eby wrote:
>>> At 07:05 PM 7/30/2008 -0500, Dave Peterson wrote:
>>>> Am I missing something or is the following a bug whereby adding the 
>>>> '.dev' tag is doing something weird?
>>>>
>>>> >>> from pkg_resources import parse_requirement as pv
>>>> >>> pv('1.0a1.dev') < pv('1.0a1')
>>>> True
>>>> >>> pv('1.0a1') < pv('1.0')
>>>> True
>>>> >>> pv('1.0a1.dev') < pv('1.0.dev')
>>>> False
>>>> >>> pv('1.0a1') < pv('1.0.dev')
>>>> False
>>>> >>> import setuptools
>>>> >>> setuptools.__version__
>>>> '0.6c8'
>>>>
>>>> This is mainly causing us problems when projects try to track alpha 
>>>> and beta level bumps in dependencies, such as when project Foo 
>>>> requires project Bar version 3.0b1 via a requirement like 'Bar >= 
>>>> 3.0b1' (which means we don't want the development prereleases of 
>>>> Bar's first beta release, but anything after that should be okay.)
>>>> But then when we actually want to release Bar 3.0 and change the 
>>>> version number to just '3.0', suddenly installs fail while we try 
>>>> to run the last set of tests because '3.0.dev' is older than '3.0b1'.
>>>>
>>>> If it is not a bug, how do you handle situations where you want to 
>>>> run that last round of testing prior to tagging and building 
>>>> releases?  I'd rather do that AFTER making all source changes, and 
>>>> not have to change the version number after the testing.
>>>
>>> This is what 'rc' tags are for, actually.  You can put your version 
>>> in the source, and use the -b option to egg_info while doing builds 
>>> and testing to tack on an 'rc' tag, possibly with a subversion 
>>> number as well.
>>
>> Perhaps I'm missing something, but that doesn't seem like it scales 
>> to a community -- not everyone is going to remember to use a '-b' 
>> option when building and that is going to cause endless support 
>> problems.
>
> Only the creator of a release uses that; the community should never be 
> building "release" versions.

Right, and that's the exact problem!  They're grabbing the source via 
svn checkout from the release tag and doing their own build which ends 
up getting labeled as '3.0.dev-r1234'  (which seems to be exactly the 
right thing to say to me -- it is an svn build of the 3.0 release) but 
this does not satisfy dependencies that are in other projects that were 
put out requiring "Traits >= 3.0b1".   Sure I can tell people not to do 
that when they say it doesn't work, but I think it should work because 
the pattern works everywhere else (see below.)


>>    We do put the following in our setup.cfg so that people don't 
>> mistakenly build release versions when not intending to do so:
>>
>> [egg_info]
>> tag_build = .dev
>> tag_svn_revision = 1
>>
>> Are you staying the standard process for setuptools is to delete / 
>> modify this when tagging a release in the repo?
>
> I personally don't tag releases in the repository; a release is not a 
> tag.  I have an alias called 'release' that maps to 'egg_info -Rdb 
> ""', and I use it when issuing release builds.

Great to hear about what you do, but we frequently have to support 
customers who need minor updates and having a tag that makes it easy to 
branch from, or re-create, a release is a very useful thing.  We have to 
many developers who need to restart at a release point to be able to 
track the code state at release points using any other method we've seen.


> However, there's nothing stopping you from creating a utility that 
> copies the trunk to a tag, checks out the tag, removes the options, 
> and checks in the tag, if that would be your preferred approach.

Hmm, and I thought I was clear saying that this is exactly what I do not 
want to do. :-)   Ideally, we don't want to modify tags in anyway.   
Like you pointed out above, I don't want people accidentally building 
'release' versions except the project maintainers.




>>   If not, how do you avoid the problem of someone building from a 
>> source checkout and finding out that 3.0.dev-r1234 doesn't satisfy 
>> the '>= 3.0b1' dependency spec?
>
> I bump the version number in SVN immediately after making a release, 
> so that the trunk would be '3.1.dev-r1234', not '3.0dev'.  If you're 
> using .dev tags in your egg-info setup, you should bump the version in 
> setup.py immediately *after* releasing, to avoid just this situation.

We DO do that.   That doesn't solve the problem I'm talking about 
though.   Let me try one more time....

There exist people who prefer to build from source they've gotten from 
the svn repo.  These people don't want to worry about bugs in the trunk 
/ development version so they go grab the source from the latest release 
tag.   They then do a "setup.py bdist_egg" to build an egg that they 
plan to distribute within their company, work group, what have you as 
part of their shared project where they defined dependencies as 
">=3.0b1"   While the latest tagged version is 3.0b1, 3.0b2, 3.0c1, 
3.0c2, etc. this process works great as all of those are correctly newer 
or equal to 3.0b1 even when .dev tags are appended to the version 
number.   BUT, as soon as we tag and release the final 3.0 release, it 
breaks because 3.0.dev < 3.0b1.   It will work fine again when we tag 
and release 3.1<anything> or 4.0<anything>.   It is only the final 
release of 3.0 that exhibits this problem. 

This seems like a bug.


-- Dave


From alberto at toscat.net  Wed Aug  6 19:15:30 2008
From: alberto at toscat.net (Alberto Valverde)
Date: Wed, 06 Aug 2008 19:15:30 +0200
Subject: [Distutils] [ANN] EggFreezer
In-Reply-To: <6e9196d20808051539m2ec4a8am4761fea6444a5f72@mail.gmail.com>
References: <48983A0E.5090902@toscat.net>
	<6e9196d20808051539m2ec4a8am4761fea6444a5f72@mail.gmail.com>
Message-ID: <4899DC32.9040604@toscat.net>

Mike Orr wrote:
> Alberto, this is a wonderful idea.  It may help with some issues  I'm
> currently facing, running Pylons on App Engine and in Py2exe,
> distributing projects to assistant developers, and in training
> sessions for new developers.
>
> My organization has developers on all three platforms (Linux, Windows,
> and Mac), so we'd definitely be interested interested in all-platform
> or cross-platform builds if they become feasable.
>   
I've implemented "universal" installer support in latest release, 0.1.4.
The support is limited however by setuptools limitation of not
distinguish between different builds (UCS2 vs UCS4 on linux, fink vs mac
ports, etc.. on macosx, etc) though this might be fixed in the future if
someone more knowledgeable than me on this issues wants to lend a hand :)

A sample universal installer for TurboGears2 which supports linux-i686,
win32 and macosx-10.3-i386 (with the mentioned limitiations) is here:
http://toscat.net/~alberto/AllTurboGears2-1.9.7a3dev-r5053-py2.5.py

Alberto

P.S: This cross-post replies are getting out of control. Since I'm the
one who began all this madness by cross-posting the announcement, I
should be one trying to stop it: Lets continue this thread in
distutils-sig please, sorry about this.

From dpeterson at enthought.com  Wed Aug  6 19:19:31 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Wed, 06 Aug 2008 12:19:31 -0500
Subject: [Distutils] Bug in setuptools version parsing when appending
 '.dev'?
In-Reply-To: <20080804223831.E8C093A40D9@sparrow.telecommunity.com>
References: <489101D1.3030903@enthought.com>
	<525f23e80808010836k62a1da8aka7daaca1b1320699@mail.gmail.com>
	<48973B6A.2010908@enthought.com>
	<525f23e80808041041q1031c449i2b50cc5762e769ad@mail.gmail.com>
	<20080804223831.E8C093A40D9@sparrow.telecommunity.com>
Message-ID: <4899DD23.2000506@enthought.com>

Phillip J. Eby wrote:
> At 01:41 PM 8/4/2008 -0400, Alexander Michael wrote:
>> Again, attempting to offer up practical solutions. Edit the
>> setup.cfg's to drop the dev option in the release branches and update
>> the trunk to the next version (i.e. 3.1.dev-rXXXXX)? That way,
>> checkouts of the release branches will be 3.0-rXXXXX (a post release
>> of 3) and the trunk will be a post of a pre-release that is newer than
>> anything else in the repository. Just a thought...
>
> This is basically what I do, except I don't bother having release 
> branches or tags, and instead of editing the setup.cfg, I just use my 
> "release" alias (which maps to 'egg_info -RDb""').

We have that alias too, which is how we build releases but everyone else 
defaults to a .dev-r1234 type of suffix on their version numbers.

> So, when I did two back-to-back releases of BytecodeAssembler today 
> (due to finding a bug after the first release), my command sequence was:
>
>    # start: version in setup.py is 0.4, release on Pypi is 0.3
>
>    # do development of version 0.4 w/periodic checkins
>    setup.py wikiup   # upload wiki pages
>    setup.py release sdist bdist_egg upload
>    # ... edit version number from 0.4 to 0.5 and check in
>
>    # ... find bug, fix it, check it in
>    setup.py wikiup   # upload wiki pages
>    setup.py release sdist bdist_egg upload
>    # ... edit version number from 0.5 to 0.6 and check in
>
>    # end: version in setup.py is 0.6, release on Pypi is 0.5

This is pretty much our exact process too!   Only difference are that we 
do alpha and beta versions in the setup.py AND we svn tag the 0.4 and 
0.5 versions.   The problem I'm having is when someone gets those tagged 
versions and does a build.  Those builds don't satisfy dependencies that 
the alpha and betas did. :-(

-- Dave


From zooko at zooko.com  Wed Aug  6 19:24:43 2008
From: zooko at zooko.com (zooko)
Date: Wed, 6 Aug 2008 11:24:43 -0600
Subject: [Distutils] [ANN] EggFreezer
In-Reply-To: <48987AD2.7000205@colorstudy.com>
References: <48983A0E.5090902@toscat.net> <489872F2.4090305@colorstudy.com>
	<489878B0.20304@toscat.net> <48987AD2.7000205@colorstudy.com>
Message-ID: <D5B907EA-AC5D-463E-9AFC-D1AEE9BD395F@zooko.com>

On Aug 5, 2008, at 10:07 AM, Ian Bicking wrote:

> No... which makes binary eggs unusable on Linux.  I feel like there  
> was something else that made binary packages on a Mac unreliable,  
> but I can't remember.

Perhaps it was http://bugs.python.org/setuptools/issue19 (Will  
setuptools on Mac Python accept fat eggs?).

Regards,

Zooko



From c.j.maddison at gmail.com  Wed Aug  6 23:40:47 2008
From: c.j.maddison at gmail.com (Chris Maddison)
Date: Wed, 6 Aug 2008 14:40:47 -0700
Subject: [Distutils] setuptools acting differently in different shell
	environments
Message-ID: <1F28C345-2AD3-4AE6-8055-4D47BE6058C2@gmail.com>

Hello Phillip J. Eby,

I am having trouble setting up an installer package on Mac OS 10.5  
that installs setuptools and nose testing for Python 2.5. The  
installer .pkg drops the payload as a temporary file with the  
distributions and runs short postinstall script to do the installation  
of the packages. The scripts I have running are fairly simple:
	
	#!/bin/sh
	cd $2nose_installer_temp
	sh setuptools-0.6c8-py2.5.egg
	easy_install -v nose
	exit 0

When I run the equivalent script as an executable outside of the  
Installer it works great:

	/Users/chris/Documents/PyGraphics/Installer/Nose/resources/ 
postinstall ; exit;
	Corbie:~ chris$ /Users/chris/Documents/PyGraphics/Installer/Nose/ 
resources/postinstall ; exit;
	Processing setuptools-0.6c8-py2.5.egg
	Removing /Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/setuptools-0.6c8-py2.5.egg
	Copying setuptools-0.6c8-py2.5.egg to /Library/Frameworks/ 
Python.framework/Versions/2.5/lib/python2.5/site-packages
	setuptools 0.6c8 is already the active version in easy-install.pth
	Installing easy_install script to /Library/Frameworks/ 
Python.framework/Versions/2.5/bin
	Installing easy_install-2.5 script to /Library/Frameworks/ 
Python.framework/Versions/2.5/bin

	Installed /Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/setuptools-0.6c8-py2.5.egg
	Processing dependencies for setuptools==0.6c8
	Finished processing dependencies for setuptools==0.6c8
	Searching for nose
	Best match: nose 0.10.3
	Processing nose-0.10.3-py2.5.egg
	nose 0.10.3 is already the active version in easy-install.pth
	Installing nosetests script to /Library/Frameworks/Python.framework/ 
Versions/2.5/bin
	changing mode of /Library/Frameworks/Python.framework/Versions/2.5/ 
bin/nosetests to 755

	Using /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ 
site-packages/nose-0.10.3-py2.5.egg
	Processing dependencies for nose
	Finished processing dependencies for nose

Note that this method has the correct default install location.
/Library/Frameworks/Python.framework/Versions/2.5/bin for scripts and / 
Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages for the modules.

When the SAME script is run as part of the installer package I get:

	error: can't create or remove files in install directory
	The following error occurred while trying to add or remove files in the
	installation directory:

	[Errno 2] No such file or directory: '/Library/Python/2.5/site- 
packages/test-easy-install-4156.write-test'

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

	/Library/Python/2.5/site-packages/

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

It seems like a different default directory is being used and I can't  
figure out why or how to change that. On top of that, when I try  
forcing it in various ways (including .cfg files) suggested in the  
setuptools documentation it says that those directories aren't in the  
python path as my $PYTHONPATH variable is ''. This is strange, because  
sys.path DOES come up with the correct paths.

I tried fooling setuptools by assigning the directory to PYTHONPATH  
and calling the installer then. It manages to get things in the right  
place, but somehow fails to configure itself properly and throws the  
following error:

	Corbie:~ chris$ easy_install nose
	Traceback (most recent call last):
	 File "/Library/Frameworks/Python.framework/Versions/Current/bin/ 
easy_install", line 5, in <module>
	   from pkg_resources import load_entry_point
	 File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/pkg_resources.py", line 2559, in <module>
	   parse_requirements(__requires__), Environment()
	 File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/pkg_resources.py", line 518, in resolve
	   raise DistributionNotFound(req)  # XXX put more info here
	pkg_resources.DistributionNotFound: setuptools==0.6c8

I don't understand why Is there some quirk of shells that I don't  
understand, does have it have something to do with different  
environment variables? Is there something in the behaviour of  
setuptools.egg that can explain this? Can you think of a way around it?

Sorry for the massive email! and thanks!
Chris Maddison

From pje at telecommunity.com  Wed Aug  6 23:57:01 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 06 Aug 2008 17:57:01 -0400
Subject: [Distutils] setuptools acting differently in different shell
 environments
In-Reply-To: <1F28C345-2AD3-4AE6-8055-4D47BE6058C2@gmail.com>
References: <1F28C345-2AD3-4AE6-8055-4D47BE6058C2@gmail.com>
Message-ID: <20080806215611.C2E013A4093@sparrow.telecommunity.com>

At 02:40 PM 8/6/2008 -0700, Chris Maddison wrote:
>It seems like a different default directory is being used and I can't
>figure out why or how to change that. On top of that, when I try
>forcing it in various ways (including .cfg files) suggested in the
>setuptools documentation it says that those directories aren't in the
>python path as my $PYTHONPATH variable is ''. This is strange, because
>sys.path DOES come up with the correct paths.

It sounds like you're using different versions of Python in the two 
environments.  That would explain everything, pretty much.  It also 
sounds like a very Mac-specific issue.

Probably the simplest workaround would be to replace the "sh 
setuptools.egg" bit with an inline version of the egg's shell code, 
that hardcodes the path to the specific version of Python you want to use.


From ianb at colorstudy.com  Thu Aug  7 00:36:46 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 06 Aug 2008 17:36:46 -0500
Subject: [Distutils] setuptools acting differently in different shell
 environments
In-Reply-To: <20080806215611.C2E013A4093@sparrow.telecommunity.com>
References: <1F28C345-2AD3-4AE6-8055-4D47BE6058C2@gmail.com>
	<20080806215611.C2E013A4093@sparrow.telecommunity.com>
Message-ID: <489A277E.5080105@colorstudy.com>

Phillip J. Eby wrote:
> At 02:40 PM 8/6/2008 -0700, Chris Maddison wrote:
>> It seems like a different default directory is being used and I can't
>> figure out why or how to change that. On top of that, when I try
>> forcing it in various ways (including .cfg files) suggested in the
>> setuptools documentation it says that those directories aren't in the
>> python path as my $PYTHONPATH variable is ''. This is strange, because
>> sys.path DOES come up with the correct paths.
> 
> It sounds like you're using different versions of Python in the two 
> environments.  That would explain everything, pretty much.  It also 
> sounds like a very Mac-specific issue.

And if you suspect this, check with "python -c 'import sys; print 
sys.executable'".  "which" sometimes lies.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From chris.arndt at web.de  Thu Aug  7 00:48:06 2008
From: chris.arndt at web.de (Christopher Arndt)
Date: Thu, 07 Aug 2008 00:48:06 +0200
Subject: [Distutils] [ANN] EggFreezer
In-Reply-To: <D5B907EA-AC5D-463E-9AFC-D1AEE9BD395F@zooko.com>
References: <48983A0E.5090902@toscat.net>
	<489872F2.4090305@colorstudy.com>	<489878B0.20304@toscat.net>
	<48987AD2.7000205@colorstudy.com>
	<D5B907EA-AC5D-463E-9AFC-D1AEE9BD395F@zooko.com>
Message-ID: <489A2A26.1040804@web.de>

zooko schrieb:
> On Aug 5, 2008, at 10:07 AM, Ian Bicking wrote:
> 
>> No... which makes binary eggs unusable on Linux.  I feel like there 
>> was something else that made binary packages on a Mac unreliable, but 
>> I can't remember.
> 
> Perhaps it was http://bugs.python.org/setuptools/issue19 (Will 
> setuptools on Mac Python accept fat eggs?).

Yes, that's what I meant. setuptools on Mac OS X 10.5 does not accept 
'fat' binary eggs build on 10.4.

Diez. R. Roggisch schrieb:
 > Why shouldn't they?

Or can you install all of the following on Leopard?

http://files.turbogears.org/eggs/simplejson-1.9.1-py2.5-macosx-10.3-fat.egg
http://files.turbogears.org/eggs/RuleDispatch-0.5a0.dev_r2306-py2.5-macosx-10.3-fat.egg
http://files.turbogears.org/eggs/PyProtocols-1.0a0dev_r2302-py2.5-macosx-10.3-fat.egg
http://files.turbogears.org/eggs/Cheetah-2.0rc8-py2.5-macosx-10.3-fat.egg

Chris

From deets at web.de  Thu Aug  7 14:01:58 2008
From: deets at web.de (Diez B. Roggisch)
Date: Thu, 7 Aug 2008 14:01:58 +0200
Subject: [Distutils] [tg-trunk] Re: [ANN] EggFreezer
In-Reply-To: <489A2A26.1040804@web.de>
References: <48983A0E.5090902@toscat.net>
	<D5B907EA-AC5D-463E-9AFC-D1AEE9BD395F@zooko.com>
	<489A2A26.1040804@web.de>
Message-ID: <200808071401.59156.deets@web.de>

On Thursday 07 August 2008 00:48:06 Christopher Arndt wrote:
> zooko schrieb:
> > On Aug 5, 2008, at 10:07 AM, Ian Bicking wrote:
> >> No... which makes binary eggs unusable on Linux.  I feel like there
> >> was something else that made binary packages on a Mac unreliable, but
> >> I can't remember.
> >
> > Perhaps it was http://bugs.python.org/setuptools/issue19 (Will
> > setuptools on Mac Python accept fat eggs?).
>
> Yes, that's what I meant. setuptools on Mac OS X 10.5 does not accept
> 'fat' binary eggs build on 10.4.

I understood your post as if fat-binaries as whole weren't supported under 
10.5, which they are.

> Diez. R. Roggisch schrieb:
>  > Why shouldn't they?
>
> Or can you install all of the following on Leopard?
>
> http://files.turbogears.org/eggs/simplejson-1.9.1-py2.5-macosx-10.3-fat.egg
> http://files.turbogears.org/eggs/RuleDispatch-0.5a0.dev_r2306-py2.5-macosx-
>10.3-fat.egg
> http://files.turbogears.org/eggs/PyProtocols-1.0a0dev_r2302-py2.5-macosx-10
>.3-fat.egg
> http://files.turbogears.org/eggs/Cheetah-2.0rc8-py2.5-macosx-10.3-fat.egg

Dunno, most probably not. But there is no problem making 10.3, 10.4 and 10.5 
available, isn't there? Inconvenient - for sure. 

But I understood the linux-problem to be that there actually is no way to 
determine if UCS2 or UCS4 is used, or at least not supported to generate 
different eggs for that - so you end up with one egg for two platforms, and 
on which it works is essentially luck.

Diez

From alberto at toscat.net  Thu Aug  7 14:28:48 2008
From: alberto at toscat.net (Alberto Valverde)
Date: Thu, 7 Aug 2008 14:28:48 +0200 (CEST)
Subject: [Distutils] [tg-trunk] Re: [ANN] EggFreezer
In-Reply-To: <4898A741.3070201@colorstudy.com>
References: <48983A0E.5090902@toscat.net> <489872F2.4090305@colorstudy.com>
	<489878B0.20304@toscat.net> <48987AD2.7000205@colorstudy.com>
	<48988471.8020703@toscat.net> <4898A741.3070201@colorstudy.com>
Message-ID: <41799.84.20.17.84.1218112128.squirrel@correo.toscat.com>


>
> Alberto Valverde wrote:
> [...]
>>> No... which makes binary eggs unusable on Linux.  I feel like there was
>>> something else that made binary packages on a Mac unreliable, but I
>>> can't remember.  Windows binary eggs generally work fine.  This is
>>> discussed some here:
>>> http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/
>>>
>>
>> I remember reading that... Perhaps a solution could be to"freeze" the
>> tar.gzs too, beside the compiled eggs in case we're lucky,  and hope
>> that a compiler + libs are there when the install script is thawed. If
>> the compiled egg won't cut it, then try to compile form source. I'm not
>> sure how to tell easy_install to download the source distributions
>> though.
>
> Well, it'll make eggs from your tarballs anyway.  Turning it into a
> build process is a bit of a nuisance... I was hoping for something that
> didn't require building, but just did installation.

Yes, installation is the primary concern. I was suggesting the possibility
of bundling the source distributions of platform dependent eggs just in
case  we can compile them by any chance if there's no pre-compiled binary
available. Just like easy_install does when downloading from an index, ut
without net access.

> That said, it might work.  Maybe PoachEggs (mentioned later) does what
> you want in this case.  Or, maybe it can be slightly modified to do what
> you want (I think it might also unintentionally turn tarballs into eggs).

I took a look at it as a source of ideas when experimenting with all this
stuff. One reason I discarded it was because I was under the impression
that you need to manually provide a requirements list and I wanted
something as automatic as possible, which you could say "get me TG + all
it's deps" and it'll use easy_install to satisfy those deps. for you.

However, no that I've looked at it more closely it seems that it can
piggy-back on virtualenv to build this list, right?

>>> One nuisance is that people don't generally know how their Python was
>>> built (UCS2 or UCS4).  I was thinking about making something very
>>> similar to eggfreezer (which I'm unlikely to do now that eggfreezer
>>> exists ;),
>> You're patches are welcomed, In fact, If you want to include it inside
>> virtualenv I would be most happy :).
>
> Not so much virtualenv, but it might fit in PoachEggs:
> https://svn.openplans.org/svn/PoachEggs/trunk
>
> workingenv did installation, but I abandoned that when I cleaned it up
> as virtualenv, and now I'm inclined to keep them separate (though
> clearly complementary).

Yes, this is probably the right thing to do, keep virtualenv simple.

> I have thought about putting something in virtualenv to make relocating
> the environment easier.  There's only a few things that need to be
> modified, I think.  That might mitigate some of these issues.

Hmm, like being able to just zip the whole virtual environment and unzip
elsewhere and it just works? That would be awesome indeed, and make
eggfreezer unnecessary except perhaps the little code to create an inline
tarball.

>>>  and generating an "install" .py file that determines the
>>> platform and downloads the appropriate platform bundle.
>>>
>>
>> Hmm, this "download" is precisely what I'm trying to avoid. My main use
>> case is: A machine has gone down and I want to quickly put back
>> everything together in another machine with a backup and something that
>> contains *all* needed software. Sort of like an apt reposisory inside a
>> dvd which lets you install debian on a machine with absolutely not net
>> access. The "no-net" condition is just there to guarantee that all deps
>> will be available no matter how old and discontinued they are (which if
>> I think about it is rather ambitious... well, at least make it more
>> likely than with the current situation)
>
> With PoachEggs I've now got it working so you can build a working
> environment, create a "requirements" file that lists everything in that
> working environment, download all the eggs for that into a directory,
> and then later install from that directory and disallow network access.
>   Well, more-or-less.  It's not a single-file install like eggfreezer,
> but they are working toward similar goals.

Yes, almost the same goals although I'd like to keep eggfreezer simple by
leaving all the hard work of finding the right distributions to
easy_install as much as possible.

Ideally eggfreezer would be just a few lines to create and read the inline
tarball if setuptools had an api like:
package_index.fetch_distribution(requirement, platform, flavor)
To get a specific distribution for a specific platform and be able to read
its requirements without installing it. In all my experiments,
Distribution.requires() returned an empty list unless the egg was
installed, that's the reason for all that mess of firing up easy_install
in a subprocess inside eggfreezer to download required distributions.

> The single-file install including binaries is something I would really
> like for Deliverance, and specifically for lxml, but also to create a
> simple installation experience for people who don't know anything about
> Python build things (and maybe don't know Python).

A "universal" lxml would be awesome indeed :)

>> I think that this multi-platform issue could be solved by bundling all
>> the different binary versions of all binary packages. However, I'm not
>> sure if pkg_resources could deal with the UCS2/UCS4 issue given that it
>> doesn't distinguish it in the platform id. Maybe by hacking in an extra
>> placeholder, before the .egg and after the ${platform}, that the script
>> uses to distinguish and then remove it before giving it to easy_install?
>> Though this smells like the root of the problem comes from setuptools
>> and should be fixed there...
>
> If you could select the appropriate binary at installation time you
> could include all of them in the bundle.  It would be big, but at least
> personally that would be fine for me.

Yeah, big installers are preferable over ten slightly smaller installers
from my point of view too.

> It would be simpler to simply
> name the resulting file with a more accurate platform, but then people
> don't always know the right thing to get.  At least a little check in
> the script itself would be helpful, so they get errors immediately
> instead of confusing errors at import time.  I'm not sure how to detect
> UCS2/UCS4.
>
> The root (well, *one* root) of the problem is setuptools/distutils not
> getting the platform really right, but there's also all kinds of messy
> backward compatibility issues there, and no backward compatibility
> issues for eggfreezer.  I'm not sure there aren't other issues.  I'm
> also not sure that there isn't a finite number of resolvable issues.  So
> maybe MacPorts and fink and system python on Macs are different.  But
> that's just 3 platforms instead of 1, it's not an infinite number.  And
> UCS2 Python is different from UCS4 on Linux, but that's really the one
> issue I know of where Linux Pythons differ.  In theory other differences
> could occur, but in practice there's maybe 10 platforms instead of 3,
> and that's not unreasonable.

I've already got an idea on how to handle these special flavors inside
eggfreezer, the only thing I'm missing are the heuristics to detect the
platform's flavor which I cannot really investigate ATM, nor in the near
future, due to lack of testing machines and experience on them (I've never
had the need to compile anything on windows and never done, for example).

So, if someone can point me to, or provide, something I can use to
reliably detect a platform and its peculiar flavor I could implement this
in short time, I guess.

> Reading a comment on the philikon article
> (http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/#comment-47),
> I also notice that Enthought has done some work on this, it seems by
> fixing up the binary packages at install time.  This seems to be related
> to an entirely different issue of the location of libraries and binary
> incompatibilities, which I only slightly understand.

Very interesting... some code doing this is not available anywhere for me
to study/steal, right? :)

Alberto


From ianb at colorstudy.com  Thu Aug  7 18:13:06 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 07 Aug 2008 11:13:06 -0500
Subject: [Distutils] [tg-trunk] Re: [ANN] EggFreezer
In-Reply-To: <41799.84.20.17.84.1218112128.squirrel@correo.toscat.com>
References: <48983A0E.5090902@toscat.net>
	<489872F2.4090305@colorstudy.com>	<489878B0.20304@toscat.net>
	<48987AD2.7000205@colorstudy.com>	<48988471.8020703@toscat.net>
	<4898A741.3070201@colorstudy.com>
	<41799.84.20.17.84.1218112128.squirrel@correo.toscat.com>
Message-ID: <489B1F12.7010305@colorstudy.com>

Alberto Valverde wrote:
>> Alberto Valverde wrote:
>> [...]
>>>> No... which makes binary eggs unusable on Linux.  I feel like there was
>>>> something else that made binary packages on a Mac unreliable, but I
>>>> can't remember.  Windows binary eggs generally work fine.  This is
>>>> discussed some here:
>>>> http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/
>>>>
>>> I remember reading that... Perhaps a solution could be to"freeze" the
>>> tar.gzs too, beside the compiled eggs in case we're lucky,  and hope
>>> that a compiler + libs are there when the install script is thawed. If
>>> the compiled egg won't cut it, then try to compile form source. I'm not
>>> sure how to tell easy_install to download the source distributions
>>> though.
>> Well, it'll make eggs from your tarballs anyway.  Turning it into a
>> build process is a bit of a nuisance... I was hoping for something that
>> didn't require building, but just did installation.
> 
> Yes, installation is the primary concern. I was suggesting the possibility
> of bundling the source distributions of platform dependent eggs just in
> case  we can compile them by any chance if there's no pre-compiled binary
> available. Just like easy_install does when downloading from an index, ut
> without net access.

Probably we're both having the same problem, which is that we're using 
easy_install to download packages, but then of course it also installs 
the packages, which is almost okay so long as you are okay with an egg. 
  But if it just downloaded, that'd be better.  I'm sure some digging 
would reveal a way to just download.

>> That said, it might work.  Maybe PoachEggs (mentioned later) does what
>> you want in this case.  Or, maybe it can be slightly modified to do what
>> you want (I think it might also unintentionally turn tarballs into eggs).
> 
> I took a look at it as a source of ideas when experimenting with all this
> stuff. One reason I discarded it was because I was under the impression
> that you need to manually provide a requirements list and I wanted
> something as automatic as possible, which you could say "get me TG + all
> it's deps" and it'll use easy_install to satisfy those deps. for you.
> 
> However, no that I've looked at it more closely it seems that it can
> piggy-back on virtualenv to build this list, right?

It lets you be more specific about packages than setup.py, but it 
doesn't require you to enumerate everything.  If you install Pylons 
it'll pick up all of Pylons' requirements.

The idea of PoachEggs, though, is that often a second-level requirement 
effects the stability of an application.  So if you require 
Pylons==0.9.6, but Pylons doesn't require a specific version of Beaker, 
you might have problems when a newer version of Beaker appears. 
Relatedly, it's awkward to even put a requirement like Pylons==0.9.6 in 
your application, and you may not know one way or the other if Pylons 
0.9.7 would work.

So PoachEggs just lets you put all these requirements in a separate 
file, outside of any setup.py.  You can also get a working environment, 
and then "freeze" the requirements to a set of exact versions of 
packages.  It's equivalent to what people are doing with custom package 
indexes.

>> I have thought about putting something in virtualenv to make relocating
>> the environment easier.  There's only a few things that need to be
>> modified, I think.  That might mitigate some of these issues.
> 
> Hmm, like being able to just zip the whole virtual environment and unzip
> elsewhere and it just works? That would be awesome indeed, and make
> eggfreezer unnecessary except perhaps the little code to create an inline
> tarball.

Well, I don't know if it would just work.  There are some paths that 
need to be fixed.  I was thinking about a specific command you'd run, 
say "python -m virtualenvmove", and it'd rewrite a few things.

But I suppose I could put a check in site.py, and do the move anytime 
site.py moves.

>>>>  and generating an "install" .py file that determines the
>>>> platform and downloads the appropriate platform bundle.
>>>>
>>> Hmm, this "download" is precisely what I'm trying to avoid. My main use
>>> case is: A machine has gone down and I want to quickly put back
>>> everything together in another machine with a backup and something that
>>> contains *all* needed software. Sort of like an apt reposisory inside a
>>> dvd which lets you install debian on a machine with absolutely not net
>>> access. The "no-net" condition is just there to guarantee that all deps
>>> will be available no matter how old and discontinued they are (which if
>>> I think about it is rather ambitious... well, at least make it more
>>> likely than with the current situation)
>> With PoachEggs I've now got it working so you can build a working
>> environment, create a "requirements" file that lists everything in that
>> working environment, download all the eggs for that into a directory,
>> and then later install from that directory and disallow network access.
>>   Well, more-or-less.  It's not a single-file install like eggfreezer,
>> but they are working toward similar goals.
> 
> Yes, almost the same goals although I'd like to keep eggfreezer simple by
> leaving all the hard work of finding the right distributions to
> easy_install as much as possible.

PoachEggs is mostly focused on finding the right distributions.

>> The root (well, *one* root) of the problem is setuptools/distutils not
>> getting the platform really right, but there's also all kinds of messy
>> backward compatibility issues there, and no backward compatibility
>> issues for eggfreezer.  I'm not sure there aren't other issues.  I'm
>> also not sure that there isn't a finite number of resolvable issues.  So
>> maybe MacPorts and fink and system python on Macs are different.  But
>> that's just 3 platforms instead of 1, it's not an infinite number.  And
>> UCS2 Python is different from UCS4 on Linux, but that's really the one
>> issue I know of where Linux Pythons differ.  In theory other differences
>> could occur, but in practice there's maybe 10 platforms instead of 3,
>> and that's not unreasonable.
> 
> I've already got an idea on how to handle these special flavors inside
> eggfreezer, the only thing I'm missing are the heuristics to detect the
> platform's flavor which I cannot really investigate ATM, nor in the near
> future, due to lack of testing machines and experience on them (I've never
> had the need to compile anything on windows and never done, for example).
> 
> So, if someone can point me to, or provide, something I can use to
> reliably detect a platform and its peculiar flavor I could implement this
> in short time, I guess.

I'm not sure, but maybe u'a'.encode('unicode_internal') shows UCS2/4?  A 
quick test appears to saw yes -- the result is 'a\x00\x00\x00' on a UCS4 
build, 'a\x00' on a UCS2 build.

>> Reading a comment on the philikon article
>> (http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/#comment-47),
>> I also notice that Enthought has done some work on this, it seems by
>> fixing up the binary packages at install time.  This seems to be related
>> to an entirely different issue of the location of libraries and binary
>> incompatibilities, which I only slightly understand.
> 
> Very interesting... some code doing this is not available anywhere for me
> to study/steal, right? :)

Probably, but you'd have to ask the Enthought guys.


-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From jeremy.kloth at gmail.com  Thu Aug  7 20:36:55 2008
From: jeremy.kloth at gmail.com (Jeremy Kloth)
Date: Thu, 7 Aug 2008 12:36:55 -0600
Subject: [Distutils] [tg-trunk] Re: [ANN] EggFreezer
In-Reply-To: <489B1F12.7010305@colorstudy.com>
References: <48983A0E.5090902@toscat.net>
	<41799.84.20.17.84.1218112128.squirrel@correo.toscat.com>
	<489B1F12.7010305@colorstudy.com>
Message-ID: <200808071236.55680.jeremy.kloth@gmail.com>

On Thu August 7 2008 10:13:06 am Ian Bicking wrote:
> I'm not sure, but maybe u'a'.encode('unicode_internal') shows UCS2/4?  A
> quick test appears to saw yes -- the result is 'a\x00\x00\x00' on a UCS4
> build, 'a\x00' on a UCS2 build.

There is also `sys.maxunicode`.  Its values are 65535 for UCS-2 and 1114111 
for UCS-4. Or, in other Python:
 "UCS-4" if sys.maxunicode > 65536 else "UCS-2"

-- 
Jeremy Kloth
http://4suite.org/

From m.van.rees at zestsoftware.nl  Thu Aug  7 20:59:43 2008
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Thu, 7 Aug 2008 18:59:43 +0000 (UTC)
Subject: [Distutils] [buildout] where does the demo egg come from in
	tests?
References: <4899DBE5.3080400@simplistix.co.uk>
Message-ID: <g7fgmv$flm$1@ger.gmane.org>

Chris Withers, on 2008-08-06:
> Hi All,
>
> I'm reading http://pypi.python.org/pypi/zc.recipe.egg#script-generation 
> with a hope to finding out how to write an egg such that I can have mroe 
> own scripts generated and called.
>
> I think having a read of the demo egg used in these tests would solve my 
> problems, but where does it live?

If I have followed the code trail correctly:

- zc/recipe/egg/tests.py has a setUp(test) function.

- This calls 'zc.buildout.tests.easy_install_SetUp(test)'.

- That function calls create_sample_eggs from that same tests.py file
  in zc.buildout.

- And that method creates some eggs on the fly.

-- 
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]


From m.van.rees at zestsoftware.nl  Thu Aug  7 22:51:45 2008
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Thu, 7 Aug 2008 20:51:45 +0000 (UTC)
Subject: [Distutils] [tg-trunk] Re: [ANN] EggFreezer
References: <48983A0E.5090902@toscat.net> <489872F2.4090305@colorstudy.com>
	<489878B0.20304@toscat.net> <48987AD2.7000205@colorstudy.com>
	<48988471.8020703@toscat.net> <4898A741.3070201@colorstudy.com>
	<41799.84.20.17.84.1218112128.squirrel@correo.toscat.com>
	<489B1F12.7010305@colorstudy.com>
Message-ID: <g7fn91$bbs$1@ger.gmane.org>

Ian Bicking, on 2008-08-07:
> Probably we're both having the same problem, which is that we're using 
> easy_install to download packages, but then of course it also installs 
> the packages, which is almost okay so long as you are okay with an egg. 
>   But if it just downloaded, that'd be better.  I'm sure some digging 
> would reveal a way to just download.

Hi,

Allow me to chip in with a few thoughts.

I have created z3c.recipe.eggbasket that may help there, if only as a
code example.  It is a recipe for zc.buildout, though you can use it
outside of a buildout with some lines of python like this:

  import z3c.recipe.eggbasket.utils

  z3c.recipe.eggbasket.utils.create_source_tarball(
      egg = 'grok',
      versionfile = 'http://grok.zope.org/releaseinfo/grok-0.13.cfg')

With those arguments it creates a tarball with grok and all its
dependencies, using the versions as specified in the versionfile.  The
tarball contains what I would call 'source eggs', so the files
downloaded from the cheese shop.  As an extra it looks for Windows
binary eggs for all those dependencies.  This is the result:

http://grok.zope.org/releaseinfo/grok-eggs-0.13.tgz

(That tarball is used within grokproject -using another part of this
same eggbasket recipe- to avoid install failures due to servers being
down, thereby lessening the number of single points of failure.  See
downloader.py.)

Look at utils.py in that package for how this is done.  The important
line is this one:

  zc.buildout.easy_install.download_cache(cache)

So zc.buildout does the real work here.  And it probably is just a
thin layer around setuptools in this spot.

BTW, this package was inspired by the zc.sourcerelease package by Jim
Fulton, stealing some ideas there.  Try that package if you want to
giftwrap a complete buildout with all source eggs and any other
downloaded stuff, including an install.py that you should run after
unpacking the generated tarball and that takes care of building up the
buildout again.

> The idea of PoachEggs, though, is that often a second-level requirement 
> effects the stability of an application.  So if you require 
> Pylons==0.9.6, but Pylons doesn't require a specific version of Beaker, 
> you might have problems when a newer version of Beaker appears. 
> Relatedly, it's awkward to even put a requirement like Pylons==0.9.6 in 
> your application, and you may not know one way or the other if Pylons 
> 0.9.7 would work.
>
> So PoachEggs just lets you put all these requirements in a separate 
> file, outside of any setup.py.  You can also get a working environment, 
> and then "freeze" the requirements to a set of exact versions of 
> packages.  It's equivalent to what people are doing with custom package 
> indexes.

Sounds like we have some overlap between PoachEggs and
z3c.recipe.eggbasket (and zc.buildout itself).

Cheers,

-- 
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]


From pje at telecommunity.com  Fri Aug  8 17:20:23 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 08 Aug 2008 11:20:23 -0400
Subject: [Distutils] setuptools tracker "needpatch" keyword, tests, etc.
Message-ID: <20080808151935.21BEC3A4093@sparrow.telecommunity.com>

Hello all.  I had some spare time the other day and went through the 
tracker, reclassifying a few things and marking some with a 
"needpatch" keyword.  The ones marked "needpatch" vary from things I 
have no idea what to do with, to ones where I've practically spelled 
out the needed patch in the tracker.

Issues with patches that passed my initial review have been marked 
"in-progress"; these could use some testing before check-in.  At this 
point, I haven't had an opportunity to review the results of the test 
sprint that was done; if somebody could throw that up as a patch on 
the tracker, or at least repost a link to where I can find that 
stuff, that would help.

All of this is with an eye to releasing an 0.6 final in the near 
future; sometime this month I'd guess/hope, depending on how my other 
projects are going.


From cgalvan at mail.utexas.edu  Fri Aug  8 17:32:56 2008
From: cgalvan at mail.utexas.edu (Chris Galvan)
Date: Fri, 08 Aug 2008 10:32:56 -0500
Subject: [Distutils] setuptools tracker "needpatch" keyword, tests, etc.
In-Reply-To: <20080808151935.21BEC3A4093@sparrow.telecommunity.com>
References: <20080808151935.21BEC3A4093@sparrow.telecommunity.com>
Message-ID: <489C6728.4010003@mail.utexas.edu>

Phillip J. Eby wrote:
> Hello all.  I had some spare time the other day and went through the 
> tracker, reclassifying a few things and marking some with a 
> "needpatch" keyword.  The ones marked "needpatch" vary from things I 
> have no idea what to do with, to ones where I've practically spelled 
> out the needed patch in the tracker.
>
> Issues with patches that passed my initial review have been marked 
> "in-progress"; these could use some testing before check-in.  At this 
> point, I haven't had an opportunity to review the results of the test 
> sprint that was done; if somebody could throw that up as a patch on 
> the tracker, or at least repost a link to where I can find that stuff, 
> that would help.
The work done on the test sprint is hosted in this bzr branch.  We 
wanted to get your feedback on what had been done so far to make sure we 
were heading in the right direction.

https://code.launchpad.net/~setuptools/setuptools-test/main

>
> All of this is with an eye to releasing an 0.6 final in the near 
> future; sometime this month I'd guess/hope, depending on how my other 
> projects are going.
That would be awesome.  To reach this goal, it would really help to get 
more tests written so that patches can be tested quicker and with more 
certainty that they haven't broken anything.

-- Chris Galvan



From pje at telecommunity.com  Fri Aug  8 18:28:26 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 08 Aug 2008 12:28:26 -0400
Subject: [Distutils] setuptools tracker "needpatch" keyword, tests, etc.
In-Reply-To: <489C6728.4010003@mail.utexas.edu>
References: <20080808151935.21BEC3A4093@sparrow.telecommunity.com>
	<489C6728.4010003@mail.utexas.edu>
Message-ID: <20080808162735.A533D3A4093@sparrow.telecommunity.com>

At 10:32 AM 8/8/2008 -0500, Chris Galvan wrote:
>Phillip J. Eby wrote:
>>Hello all.  I had some spare time the other day and went through 
>>the tracker, reclassifying a few things and marking some with a 
>>"needpatch" keyword.  The ones marked "needpatch" vary from things 
>>I have no idea what to do with, to ones where I've practically 
>>spelled out the needed patch in the tracker.
>>
>>Issues with patches that passed my initial review have been marked 
>>"in-progress"; these could use some testing before check-in.  At 
>>this point, I haven't had an opportunity to review the results of 
>>the test sprint that was done; if somebody could throw that up as a 
>>patch on the tracker, or at least repost a link to where I can find 
>>that stuff, that would help.
>The work done on the test sprint is hosted in this bzr branch.  We 
>wanted to get your feedback on what had been done so far to make 
>sure we were heading in the right direction.
>
>https://code.launchpad.net/~setuptools/setuptools-test/main

My initial reaction is that it's off to a good start, but the tests 
themselves seem rather shallow; more like "smoke tests" (i.e., turn 
it on and see if smoke comes out) than functional tests.

I'm thinking it might help to use the setuptools.sandbox facility to 
log files created, deleted, modified, etc. by the process.  That 
would probably be a better test of what has/hasn't been done than 
using ellipses on the logs, which is order-dependent as well as 
having the ability to skip lines where the wrong thing is being done, 
etc.  The way things are being done now, they probably won't be able 
to test some of the things that are most likely to break (i.e., the 
complexities of easy_install).

(Probably in order to do that I'll need to add a new sandboxing class 
that creates a "mock" filesystem and allows before/after expectations 
to be set.)


From ianb at colorstudy.com  Fri Aug  8 18:57:27 2008
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 08 Aug 2008 11:57:27 -0500
Subject: [Distutils] setuptools tracker "needpatch" keyword, tests, etc.
In-Reply-To: <20080808162735.A533D3A4093@sparrow.telecommunity.com>
References: <20080808151935.21BEC3A4093@sparrow.telecommunity.com>	<489C6728.4010003@mail.utexas.edu>
	<20080808162735.A533D3A4093@sparrow.telecommunity.com>
Message-ID: <489C7AF7.7030808@colorstudy.com>

Phillip J. Eby wrote:
> At 10:32 AM 8/8/2008 -0500, Chris Galvan wrote:
>> Phillip J. Eby wrote:
>>> Hello all.  I had some spare time the other day and went through the 
>>> tracker, reclassifying a few things and marking some with a 
>>> "needpatch" keyword.  The ones marked "needpatch" vary from things I 
>>> have no idea what to do with, to ones where I've practically spelled 
>>> out the needed patch in the tracker.
>>>
>>> Issues with patches that passed my initial review have been marked 
>>> "in-progress"; these could use some testing before check-in.  At this 
>>> point, I haven't had an opportunity to review the results of the test 
>>> sprint that was done; if somebody could throw that up as a patch on 
>>> the tracker, or at least repost a link to where I can find that 
>>> stuff, that would help.
>> The work done on the test sprint is hosted in this bzr branch.  We 
>> wanted to get your feedback on what had been done so far to make sure 
>> we were heading in the right direction.
>>
>> https://code.launchpad.net/~setuptools/setuptools-test/main
> 
> My initial reaction is that it's off to a good start, but the tests 
> themselves seem rather shallow; more like "smoke tests" (i.e., turn it 
> on and see if smoke comes out) than functional tests.
> 
> I'm thinking it might help to use the setuptools.sandbox facility to log 
> files created, deleted, modified, etc. by the process.  That would 
> probably be a better test of what has/hasn't been done than using 
> ellipses on the logs, which is order-dependent as well as having the 
> ability to skip lines where the wrong thing is being done, etc.  The way 
> things are being done now, they probably won't be able to test some of 
> the things that are most likely to break (i.e., the complexities of 
> easy_install).
> 
> (Probably in order to do that I'll need to add a new sandboxing class 
> that creates a "mock" filesystem and allows before/after expectations to 
> be set.)

You could also use ScriptTest: http://pythonpaste.org/scripttest/ -- it 
doesn't make any attempt to mock anything out, but it does keep track of 
what a command does.  For testing PoachEggs 
(https://svn.openplans.org/svn/PoachEggs/trunk/poacheggs-tests) I'm 
creating a scratch virtualenv for the test, then running things inside 
there.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org

From sklein at cpcug.org  Fri Aug  8 21:29:29 2008
From: sklein at cpcug.org (Stanley A. Klein)
Date: Fri, 8 Aug 2008 15:29:29 -0400 (EDT)
Subject: [Distutils] Problem using ETSProjectTools rpms
Message-ID: <41397.207.188.248.157.1218223769.squirrel@www.cpcug.org>

I downloaded ETSProjectTools and used "python setup.py bdist_rpm" to build
the rpms.  I did this on both Fedora 7 and Centos 5.2.

In both cases I had the rpm for python-configobj installed.

I don't know why, but during the builds the setup went out to the net to
find configobj.  It found it (although I don't know what it did with it)
and the builds completed properly.  (The setup.cfg had the proper
statements in it for doing bdist_rpm and putting files in the right
places, including docs.)

However, after I installed (using rpm) and went to run ets, I got a
traceback complaining about not being able to find configobj.

I was able to fix it by going into the egg-info directory and editing
requires.txt to comment out configobj.

I don't know if this is a problem in the ETS setup.py or the
distutils/setuptools, but there ought to be a way to fix it without having
to hack the files in the egg-info directory.  Either whatever is doing the
"requires" function ought to be able to see that configobj.py was sitting
right there in site-packages or there ought to be a way to tell the
setup.py call to ignore the "requires" functionality for configobj.


Stan Klein






From ben+python at benfinney.id.au  Sat Aug  9 04:41:09 2008
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 09 Aug 2008 12:41:09 +1000
Subject: [Distutils] How to create deb package
References: <48918A13.1000903@vsb.cz>
Message-ID: <87skte52re.fsf@benfinney.id.au>

Lum?r Jasiok <lumir.jasiok at vsb.cz> writes:

> I need to create .deb package from source package. I am using
> distutils.

To create a Debian package requires more input from the person doing
the packaging than what distutils usually requires.

Packages of Python distributions for Debian are constructed using the
usual Debian tools, including creating a 'debian/rules' file with the
required targets and whatever specific actions need to be performed in
those targets.

For invoking distutils, usually the 'build' and 'install' targets will
invoke the 'setup.py' (with 'build' or 'install' respectively) and use
the packages 'python-central' or 'python-support' to gather the
resulting files into the correct places for a Debian package.

> Is there some working bdist_deb extension? What is best practices at
> this case?

I don't know what efforts there may be in that direction, but it would
certainly require a significant amount of input from the person doing
the packaging; more than can be found in an average package from PyPI.

That input is usually provided by just following the process of
building any Debian package, whether Python or not, using Debian
developer tools (including the Python-specific 'python-central' or
'python-support' packages) instead of building it into distutils.

-- 
 \        ?Pinky, are you pondering what I'm pondering?? ?Wuh, I think |
  `\   so, Brain, but if we didn't have ears, we'd look like weasels.? |
_o__)                                           ?_Pinky and The Brain_ |
Ben Finney


From marius at pov.lt  Sat Aug  9 15:14:46 2008
From: marius at pov.lt (Marius Gedminas)
Date: Sat, 9 Aug 2008 16:14:46 +0300
Subject: [Distutils] How to create deb package
In-Reply-To: <48918A13.1000903@vsb.cz>
References: <48918A13.1000903@vsb.cz>
Message-ID: <20080809131446.GA10793@fridge.pov.lt>

On Thu, Jul 31, 2008 at 11:46:59AM +0200, Lum?r Jasiok wrote:
> I need to create .deb package from source package. I am using distutils.
> 
> Is there some working bdist_deb extension? What is best practices at 
> this case?
> 
> Any useful comments will be appreciate.

Check out http://stdeb.python-hosting.com/ and, perhaps, the other tools
and documents referenced from there.

Marius Gedminas
-- 
As easy as 3.14159265358979323846264338327950288419716
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080809/e13a50c9/attachment.pgp>

From sklein at cpcug.org  Sat Aug  9 18:15:35 2008
From: sklein at cpcug.org (Stanley A. Klein)
Date: Sat, 9 Aug 2008 12:15:35 -0400 (EDT)
Subject: [Distutils] Strange naming problem trying to build Enable rpm
Message-ID: <39832.71.163.209.137.1218298535.squirrel@www.cpcug.org>

I was able to build rpms for Traits, Envisage, and related packages (e.g.,
TraitsGUI) for Fedora 7.  However, when I tried to package Enable I ran
into the following problem:  The tar.gz gets built as
Enable-3.0.0.dev-r21092.tar.gz, but when the rpm packager gets called it
looks for Enable-3.0.0.tar.gz, doesn't find it, and errors out.  I've
copied a relevant part of the output below.

I modified the setup.cfg file for bdist_rpm (similarly to what I did for
the other packages I built) and have copied it below.

I don't know where the tar.gz name is set or where the name being looked
for by rpm is set.  I also don't know if this is an issue with the Enable
setup files or with distutils/setuptools, so I'm including both lists.

How do I get the proper names set?


Stan Klein


---------------------------------------------------------------------------
Packaging error output:

copying dist/Enable-3.0.0.dev-r21092.tar.gz ->
build/bdist.linux-i686/rpm/SOURCES
building RPMs
rpmbuild -ba --define _topdir
/home/stan/svn/ets/ETS_3.0.0/Enable_3.0.0/build/bdist.linux-i686/rpm
--clean build/bdist.linux-i686/rpm/SPECS/Enable.spec
error: File
/home/stan/svn/ets/ETS_3.0.0/Enable_3.0.0/build/bdist.linux-i686/rpm/SOURCES/Enable-3.0.0.tar.gz:
No such file or directory
error: command 'rpmbuild' failed with exit status 1

---------------------------------------------------------------------------

setup.cfg:

[egg_info]
tag_build = .dev
tag_svn_revision = 1

[aliases]
release = egg_info -RDb ''

[nosetests]
verbosity = 0
with-doctest = 1
detailed-errors = 1
with-coverage = 1
tests =
enthought/enable/tests,enthought/enable2/tests,enthought/kiva/tests,enthought/kiva/agg/tests
#
# The following directories are included in the tests option above, when
# the line starts with '# test '.  To make changes in the tests option above
# run the script update_setup_cfg.py.
#
# test enthought/enable/tests
# test enthought/enable2/tests
# test enthought/kiva/tests
# test enthought/kiva/agg/tests
#
# Note:
#   The package enthought.enable2 is a proxy to enthought.enable and
#   the tests in 'enthought/enable2/tests' are testing this proxy.

[install]
optimize = 1



[bdist_rpm]
doc_files = docs/  examples/  README.txt  LICENSE.txt







From cdunn2001 at gmail.com  Sun Aug 10 15:19:42 2008
From: cdunn2001 at gmail.com (Christopher Dunn)
Date: Sun, 10 Aug 2008 08:19:42 -0500
Subject: [Distutils] wishlist for setuptools
Message-ID: <38a615e40808100619m4ff0545dq24bc27f50fac4b8d@mail.gmail.com>

In a nutshell, here is what I want to be able to do:

   1. Download several Python eggs into a directory, including multiple
   versions of some eggs.
   2. Add that directory to sys.path at runtime.
   3. Use pkg_resources.require() to select versions of the eggs.
   4. 'import Foo' for each package "Foo".

Python Eggs are great, but I have a major problem with setuptools: Where I
work, I am not allowed to alter PYTHONPATH or to install into site-packages.
 I can add paths to sys.path at runtime, but normally we load modules via
sys.meta_path.  We have a large database of modules by many different
developers, and we have per-project configuration files which select
versions of these modules to be accessible via sys.meta_path.  I'd like to
continue to select our own modules via the configuration files, but I'd like
to load Eggs from PYPI via the procedure above.

This may seem impossible, but I have a fairly simple solution: Put an Egg
importer on sys.meta_path.  I'll outline the solution:

First, realize that no site.py or .pth files will be processed in this usage
model.

Second, when a version range is specified via pkg_resources.require(),
register that specification into a global Egg importer (attached to the
setuptools module).  Also, append that importer to the end of sys.meta_path,
if that has not already been done.  This Egg importer should follow the
protocol of PEP 302.

Third, when a module registered as an Egg is imported, Python will first
look for an importer on sys.meta_path.  If not intercepted by another
meta_path importer, eventually our new Egg importer will be tried.  The Egg
importer should search for the Egg by scanning sys.path, in order.  It
should look not only for Eggs, but also for directories which might contain
Eggs.  It should accept the first Egg discovered which matches the
registered criteria and load it. Otherwise, it should throw an ImportError
exception.

Some things to note about this approach:

   1. sys.path_hooks is ignored.  This is because the call to require()
   implied a change in import semantics.
   2. If an egg is not registered via 'require', then the Egg importer on
   sys.meta_path will not look for it, but the egg can still be loaded if it
   was 'easy_installed' and if the site.py and .pth files were properly read.
    In other words, we have complete backward-compatibility.
   3. If an appropriate egg cannot be found, the ImportError is raised at
   'import' time, not when 'require()' is called.  For this reason, we may need
   a different 'require' function, maybe 'eggs.require()'.  Or, sys.path could
   be scanned inside 'require()'.
   4. We have eliminated the O(n^2) look-up cost of a large number of eggs
   listed on sys.path directly.  In fact, we don't have to put any eggs on
   sys.path, but if we do, they will take precedence over later eggs or
   directories containing eggs, as a user would expect.

I hope that everyone takes this request seriously.  The current system is
almost completely broken for me.  The only way I can use eggs is to add each
one to sys.path explicitly at runtime.  That's a huge PITA and a big
maintenance problem.  I'm very disappointed by the whole PYPI system at the
moment.  Something that could be extremely easy is instead very difficult.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080810/5e8b31e7/attachment.htm>

From pje at telecommunity.com  Sun Aug 10 16:13:35 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 10 Aug 2008 10:13:35 -0400
Subject: [Distutils] wishlist for setuptools
In-Reply-To: <38a615e40808100619m4ff0545dq24bc27f50fac4b8d@mail.gmail.co
 m>
References: <38a615e40808100619m4ff0545dq24bc27f50fac4b8d@mail.gmail.com>
Message-ID: <20080810141245.6F66C3A403D@sparrow.telecommunity.com>

At 08:19 AM 8/10/2008 -0500, Christopher Dunn wrote:

>In a nutshell, here is what I want to be able to do:
>    * Download several Python eggs into a directory, including 
> multiple versions of some eggs.
>    * Add that directory to sys.path at runtime.
>    * Use pkg_resources.require() to select versions of the eggs.
>    * 'import Foo' for each package "Foo".
You can do all of the above now.  Just use the -m option to 
easy_install when you eggs to the non-site directory, and make sure 
that you add the directory to sys.path *before* importing 
pkg_resources.  Or, if you can't do that, do this:

     pkg_resources.working_set.add_entry(directory_just_added_to_sys_path)

This will allow pkg_resources to find eggs in that directory when you 
use require().


>I hope that everyone takes this request seriously.  The current 
>system is almost completely broken for me.  The only way I can use 
>eggs is to add each one to sys.path explicitly at runtime.

My guess is that you're probably importing pkg_resources before you 
add your egg directory to sys.path.  If not, please post code to show 
what you're doing.  You should be able to do exactly what you 
specified above, without any changes to setuptools or pkg_resources.


From zooko at zooko.com  Mon Aug 11 04:39:30 2008
From: zooko at zooko.com (zooko)
Date: Sun, 10 Aug 2008 20:39:30 -0600
Subject: [Distutils] How to create deb package
In-Reply-To: <48918A13.1000903@vsb.cz>
References: <48918A13.1000903@vsb.cz>
Message-ID: <52E030A8-224A-4010-A222-5D245AA6BF82@zooko.com>

On Jul 31, 2008, at 3:46 AM, Lum?r Jasiok wrote:

> I need to create .deb package from source package. I am using  
> distutils.
>
> Is there some working bdist_deb extension? What is best practices  
> at this case?

Please try stdeb [1] and let us know how it works for you.  It works  
for me for a few small Python projects (including zfec [2],  
pycryptopp [3], and pyutil [4]).

However, it is still a young tool and you should be willing to report  
bugs if you try it.

By the way, I've contributed a patch for stdeb which is not yet in  
the current release of stdeb which makes it automatically detect  
which debian packages your package depends on, using the  
"install_requires" field from the setup() args: [5].

Thank you for your help in improving Python packaging tools!

Regards,

Zooko

[1] http://stdeb.python-hosting.com
[2] http://allmydata.org/trac/zfec/
[3] http://allmydata.org/trac/pycryptopp/
[4] http://allmydata.org/trac/pyutil
[5] http://mail.python.org/pipermail/distutils-sig/2008-June/009632.html

From jim at zope.com  Mon Aug 11 16:19:32 2008
From: jim at zope.com (Jim Fulton)
Date: Mon, 11 Aug 2008 10:19:32 -0400
Subject: [Distutils] [buildout] weird behaviour of first buildout on
	windows...
In-Reply-To: <48982621.6010802@simplistix.co.uk>
References: <48982621.6010802@simplistix.co.uk>
Message-ID: <C92F00F6-93D3-4D85-A784-1FA0B428DFFC@zope.com>

I'll look into this.

Jim

On Aug 5, 2008, at 6:06 AM, Chris Withers wrote:

> Hi All,
>
> Looks like something weird is happening:
>
> C:\aproject\trunk>python bootstrap.py
> <snip>
> C:\aproject\trunk>bin\buildout.exe
> Getting distribution for 'zc.buildout'.
> Getting distribution for 'setuptools'.
> Got setuptools 0.6c8.
> Got zc.buildout 1.1.1.
>
> C:\aproject\trunk>Upgraded:
>  zc.buildout version 1.1.1,
>  setuptools version 0.6c8;
> restarting.
>
> At this point here, it looks like buildout is running in some kind  
> of backgrounded process, which means that:
>
> - if I hit enter while it's still progressing, I get things like:
>
> """
> Getting distribution for 'zope.testing'.
>
> C:\aproject\trunk>
> C:\aproject\trunk>
> C:\aproject\trunk>Got zope.testing 3.6.0.
> bin\                   bin\buildout.exeGetting distribution for  
> 'zope.interface'
> .                                                               Got  
> zope.interfa
> """
>
> - I don't know when buildout is finished because the command prompt  
> was echoed way back in the middle of things.
>
> NB: This only appears to happen the first time setuptools and  
> buildout are installed. Further run of bin\buildout don't exhibit  
> this behaviour.
>
> cheers,
>
> Chris
>
> -- 
> Simplistix - Content Management, Zope & Python Consulting
>           - http://www.simplistix.co.uk
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

--
Jim Fulton
Zope Corporation



From jim at zope.com  Mon Aug 11 17:13:55 2008
From: jim at zope.com (Jim Fulton)
Date: Mon, 11 Aug 2008 11:13:55 -0400
Subject: [Distutils] [buildout] where does the demo egg come from in
	tests?
In-Reply-To: <4899DBE5.3080400@simplistix.co.uk>
References: <4899DBE5.3080400@simplistix.co.uk>
Message-ID: <37E05B3A-F8A9-4E50-A17B-E19608F605B4@zope.com>


On Aug 6, 2008, at 1:14 PM, Chris Withers wrote:

> Hi All,
>
> I'm reading http://pypi.python.org/pypi/zc.recipe.egg#script-generation 
>  with a hope to finding out how to write an egg such that I can have  
> mroe own scripts generated and called.


See:

   http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation

Jim

--
Jim Fulton
Zope Corporation



From zooko at zooko.com  Mon Aug 11 19:43:42 2008
From: zooko at zooko.com (zooko)
Date: Mon, 11 Aug 2008 11:43:42 -0600
Subject: [Distutils] patch: document "Framework :: Setuptools Plugin" and
	conventions for revision control plugins
Message-ID: <99D89623-D131-4C00-B361-2EB72A08287F@zooko.com>

Folks:

Part of this patch documents the existence of the "Framework ::  
Setuptools Plugin" classifier and says when to use it.

Another part documents the naming conventions which the developers of  
the various revision control plugins agreed to.

Regards,

Zooko

P.S.  Note that the git and hg revision control plugins didn't yet go  
through a renaming to conform to the agreed convention.  I did for  
the setuptools_darcs plugin that I maintain -- you can see the  
leftover evidence of it here:

http://pypi.python.org/pypi/setuptools_darcs_plugin

I'm Cc:'ing the maintainers of the setuptools-git and setuptools-hg  
plugins to remind them of the existence of this convention in case  
they want to switch.


diff -rN -u old-dw/setuptools.txt new-dw/setuptools.txt
--- old-dw/setuptools.txt	2008-08-11 11:38:07.000000000 -0600
+++ new-dw/setuptools.txt	2008-08-11 11:38:07.000000000 -0600
@@ -2384,6 +2384,16 @@
  how setuptools' own commands are installed: the setuptools  
project's setup
  script defines entry points for them!

+If your command would be useful to other Python developers, then  
consider
+uploading it to the `Python Package Index`_.  If you do, please  
include the
+Trove Classifier "Framework :: Setuptools Plugin" in the classifiers  
so that
+your command will appear in the list of `packages which are setuptools
+plugins`_.
+
+.. _Python Package Index: http://pypi.python.org/pypi
+.. _packages which are setuptools plugins: http://pypi.python.org/ 
pypi?:action=browse&c=524
+
+

  Adding ``setup()`` Arguments
  ----------------------------
@@ -2546,6 +2556,17 @@
    control system itself.  It *may*, however, use  
``distutils.log.warn()`` to
    inform the user of the missing program(s).

+Please model your naming conventions and documentation after the other
+setuptools revision control plugins: `setuptools_bzr`_,  
`setuptools_mtn`_,'
+`setuptools_darcs`_.  Please include the Trove Classifier "Framework ::
+Setuptools Plugin" in the classifiers so that your command will  
appear in the
+list of `packages which are setuptools plugins`_.
+
+.. _setuptools_bzr: http://pypi.python.org/pypi/setuptools_bzr
+.. _setuptools_mtn: http://pypi.python.org/pypi/setuptools_mtn
+.. _setuptools_darcs: http://pypi.python.org/pypi/setuptools_darcs
+.. _packages which are setuptools plugins: http://pypi.python.org/ 
pypi?:action=browse&c=524
+

  Subclassing ``Command``
  -----------------------
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: doc-classifier-and-rcs.diff.txt
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080811/e57d27c9/attachment.txt>

From dpeterson at enthought.com  Mon Aug 11 19:51:33 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Mon, 11 Aug 2008 12:51:33 -0500
Subject: [Distutils] [Enthought-dev] Strange naming problem trying to
 build Enable rpm
In-Reply-To: <39832.71.163.209.137.1218298535.squirrel@www.cpcug.org>
References: <39832.71.163.209.137.1218298535.squirrel@www.cpcug.org>
Message-ID: <48A07C25.3010904@enthought.com>

Stanley A. Klein wrote:
> I was able to build rpms for Traits, Envisage, and related packages (e.g.,
> TraitsGUI) for Fedora 7.  However, when I tried to package Enable I ran
> into the following problem:  The tar.gz gets built as
> Enable-3.0.0.dev-r21092.tar.gz, but when the rpm packager gets called it
> looks for Enable-3.0.0.tar.gz, doesn't find it, and errors out.  I've
> copied a relevant part of the output below.
>   

I'm not sure what's happening here since the setup.cfg's for the ETS 
projects should all be pretty close to the same on this issue.   Are you 
doing a "setup.py release bdist_rpm"?  i.e. using the release alias?  If 
not, that's the source of the problem.

BTW: Are you checking in your changes to setup.cfg's?  If you don't have 
privileges, I can make these changes so just send me a patch, set of 
modified setup.cfgs, or instructions on what to do to reproduce your 
changes.

-- Dave


From sdouche at gmail.com  Mon Aug 11 20:24:00 2008
From: sdouche at gmail.com (Sebastien Douche)
Date: Mon, 11 Aug 2008 20:24:00 +0200
Subject: [Distutils] Best way to mirror Pypi
Message-ID: <5e1183fa0808111124x21b59a0dy5352129d713cc32@mail.gmail.com>

Hi there :),
We use intensively Setuptools and buildout and we are looking to
increase downloading and checking speeds. What are elegant solutions ?
The best way is to mirror also eggs (like a mirror debian for ex.),
but it's maybe to heavy for pypi machine.

Thx.

-- 
Seb

From lists at zopyx.com  Mon Aug 11 20:33:00 2008
From: lists at zopyx.com (Andreas Jung)
Date: Mon, 11 Aug 2008 20:33:00 +0200
Subject: [Distutils] Best way to mirror Pypi
In-Reply-To: <5e1183fa0808111124x21b59a0dy5352129d713cc32@mail.gmail.com>
References: <5e1183fa0808111124x21b59a0dy5352129d713cc32@mail.gmail.com>
Message-ID: <F677B4505702273AD5C71002@[192.168.0.24]>



--On 11. August 2008 20:24:00 +0200 Sebastien Douche <sdouche at gmail.com> 
wrote:

> Hi there :),
> We use intensively Setuptools and buildout and we are looking to
> increase downloading and checking speeds. What are elegant solutions ?
> The best way is to mirror also eggs (like a mirror debian for ex.),
> but it's maybe to heavy for pypi machine.
>

Please check with the catalog-sig mailinglist. We just discussed this issue.

-aj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080811/29d8aaad/attachment.pgp>

From sklein at cpcug.org  Mon Aug 11 21:09:55 2008
From: sklein at cpcug.org (Stanley A. Klein)
Date: Mon, 11 Aug 2008 15:09:55 -0400 (EDT)
Subject: [Distutils] Enthought-dev Digest, Vol 48, Issue 49
In-Reply-To: <mailman.1683.1218478613.10533.enthought-dev@mail.enthought.com>
References: <mailman.1683.1218478613.10533.enthought-dev@mail.enthought.com>
Message-ID: <11240.207.188.248.157.1218481795.squirrel@www.cpcug.org>

Dave -

I wasn't using the release alias.  From what you say, I suppose I should.

I think the Enable project might be somewhat different from the others
because it uses both distutils and setuptools.

I will send you off line a program I used that fixes up the setup.cfg.


Stan Klein



On Mon, August 11, 2008 2:16 pm, enthought-dev-request at mail.enthought.com
> Message: 5
> Date: Mon, 11 Aug 2008 12:51:33 -0500
> From: Dave Peterson <dpeterson at enthought.com>
> Subject: Re: [Enthought-dev] Strange naming problem trying to build
> 	Enable rpm
> To: enthought-dev at mail.enthought.com
> Cc: distutils-sig at python.org
> Message-ID: <48A07C25.3010904 at enthought.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Stanley A. Klein wrote:
>> I was able to build rpms for Traits, Envisage, and related packages
>> (e.g.,
>> TraitsGUI) for Fedora 7.  However, when I tried to package Enable I ran
>> into the following problem:  The tar.gz gets built as
>> Enable-3.0.0.dev-r21092.tar.gz, but when the rpm packager gets called it
>> looks for Enable-3.0.0.tar.gz, doesn't find it, and errors out.  I've
>> copied a relevant part of the output below.
>>
>
> I'm not sure what's happening here since the setup.cfg's for the ETS
> projects should all be pretty close to the same on this issue.   Are you
> doing a "setup.py release bdist_rpm"?  i.e. using the release alias?  If
> not, that's the source of the problem.
>
> BTW: Are you checking in your changes to setup.cfg's?  If you don't have
> privileges, I can make these changes so just send me a patch, set of
> modified setup.cfgs, or instructions on what to do to reproduce your
> changes.
>
> -- Dave
>



From sklein at cpcug.org  Mon Aug 11 21:25:54 2008
From: sklein at cpcug.org (Stanley A. Klein)
Date: Mon, 11 Aug 2008 15:25:54 -0400 (EDT)
Subject: [Distutils] [Enthought-dev] Strange naming problem trying to
 build Enable rpm
Message-ID: <11245.207.188.248.157.1218482754.squirrel@www.cpcug.org>

[Oops.  Re-sent to fix the subject line]

Dave -

I wasn't using the release alias.  From what you say, I suppose I should.

I think the Enable project might be somewhat different from the others
because it uses both distutils and setuptools.

I will send you off line a program I used that fixes up the setup.cfg.


Stan Klein



On Mon, August 11, 2008 2:16 pm, enthought-dev-request at mail.enthought.com
> Message: 5
> Date: Mon, 11 Aug 2008 12:51:33 -0500
> From: Dave Peterson <dpeterson at enthought.com>
> Subject: Re: [Enthought-dev] Strange naming problem trying to build
> 	Enable rpm
> To: enthought-dev at mail.enthought.com
> Cc: distutils-sig at python.org
> Message-ID: <48A07C25.3010904 at enthought.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Stanley A. Klein wrote:
>> I was able to build rpms for Traits, Envisage, and related packages (e.g.,
>> TraitsGUI) for Fedora 7.  However, when I tried to package Enable I ran
into the following problem:  The tar.gz gets built as
>> Enable-3.0.0.dev-r21092.tar.gz, but when the rpm packager gets called
it looks for Enable-3.0.0.tar.gz, doesn't find it, and errors out. 
I've copied a relevant part of the output below.
>>
>
> I'm not sure what's happening here since the setup.cfg's for the ETS
projects should all be pretty close to the same on this issue.   Are you
doing a "setup.py release bdist_rpm"?  i.e. using the release alias?  If
not, that's the source of the problem.
>
> BTW: Are you checking in your changes to setup.cfg's?  If you don't have
privileges, I can make these changes so just send me a patch, set of
modified setup.cfgs, or instructions on what to do to reproduce your
changes.
>
> -- Dave
>




-- 
Stanley A. Klein, D.Sc.
Managing Principal
Open Secure Energy Control Systems, LLC
8070 Georgia Avenue
Silver Spring, MD 20910
301-565-4025



From dpeterson at enthought.com  Mon Aug 11 21:34:05 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Mon, 11 Aug 2008 14:34:05 -0500
Subject: [Distutils] Enthought-dev Digest, Vol 48, Issue 49
In-Reply-To: <11240.207.188.248.157.1218481795.squirrel@www.cpcug.org>
References: <mailman.1683.1218478613.10533.enthought-dev@mail.enthought.com>
	<11240.207.188.248.157.1218481795.squirrel@www.cpcug.org>
Message-ID: <48A0942D.3020403@enthought.com>

Hi Stan,

Stanley A. Klein wrote:
> Dave -
>
> I wasn't using the release alias.  From what you say, I suppose I should.
>   

If you're trying to build rpms for the equivalent of the released 
sdist's and eggs, then yes, you definitely should.  If you look at the 
setup.cfg files in all ETS projects, they all  append build tags of 
'.dev' and force the svn revision to be tagged on, UNLESS you trigger 
the release alias or explicitly specify "egg_info -RDb".
 

> I think the Enable project might be somewhat different from the others
> because it uses both distutils and setuptools.
>   

Nope, not at all.   We have a number of other projects using 
numpy.distutils and setuptools together in ETS.


> I will send you off line a program I used that fixes up the setup.cfg.
>
>   

Excellent.  Thanks!

-- Dave


From lists at zopyx.com  Tue Aug 12 13:16:47 2008
From: lists at zopyx.com (Andreas Jung)
Date: Tue, 12 Aug 2008 13:16:47 +0200
Subject: [Distutils] Setuptools reindenting reST documentation?
Message-ID: <BC1A7F0E6D52CDBEC56AA399@[192.168.0.24]>

Hi there,

I have a reST documentation containing something like that

blablabla::

  foo foo foo
  foo foo foo

used as long_description.

After building the egg the PKG-INFO file
contains the text with the same indentation level.

I came across this issue because rst2html.py
did not complain before building the egg but
a later conversion of the reST document taken
from the PKG-INFO produced serveral errors.

Why is setuptools doing that?

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080812/6607795f/attachment.pgp>

From setuptools at bugs.python.org  Tue Aug 12 14:21:30 2008
From: setuptools at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 12 Aug 2008 12:21:30 +0000
Subject: [Distutils] [issue32] Make setuptools hanlde multiple index
	locations (index url)
In-Reply-To: <1218543690.31.0.115931774796.issue32@psf.upfronthosting.co.za>
Message-ID: <1218543690.31.0.115931774796.issue32@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

PyPI mirrors and alternative packages servers are starting to appear. To be able
to use them efficiently, setuptools should be able to handle a list of index url
instead of a single one.

That would involve playing with several instance of PackageIndex but would allow
retrieving packages from several sources, whether they are mirrors or
alternative package servers.

----------
messages: 80
nosy: tarek
priority: feature
status: unread
title: Make setuptools hanlde multiple index locations (index url)

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

From uschmitt at mineway.de  Tue Aug 12 15:37:42 2008
From: uschmitt at mineway.de (Uwe Schmitt)
Date: Tue, 12 Aug 2008 15:37:42 +0200
Subject: [Distutils] My first egg
Message-ID: <48A19226.3050603@mineway.de>

Hi,

I just finished my first egg, but have a question:
How can I distribute example scripts for my
package ???

Greetings, Uwe

-- 
Dr. rer. nat. Uwe Schmitt
F&E Mathematik
 
mineway GmbH
Science Park 2
D-66123 Saarbr?cken
 
Telefon: +49 (0)681 8390 5334
Telefax: +49 (0)681 830 4376
 
uschmitt at mineway.de
www.mineway.de
 
Gesch?ftsf?hrung: Dr.-Ing. Mathias Bauer
Amtsgericht Saarbr?cken HRB 12339



From cdcasey at gmail.com  Tue Aug 12 16:04:44 2008
From: cdcasey at gmail.com (chris)
Date: Tue, 12 Aug 2008 09:04:44 -0500
Subject: [Distutils] specify available build commands
Message-ID: <ead057790808120704q5c82ca6apa21e4d7fd3b169cc@mail.gmail.com>

Is there a way in distutils / setuptools to list the available build
commands via porperty or function?

Specifically, I want to be able to add a configuration and build some
classes only if one of these commands is specified.

python setup.py build <----- confuguration added
python setup.py sdist bdist_egg <----- confuguration added
python setup.py sdist <----- confuguration not added

Maybe there's a better way to do it.

-Chris

From cgalvan at mail.utexas.edu  Tue Aug 12 16:14:44 2008
From: cgalvan at mail.utexas.edu (Chris Galvan)
Date: Tue, 12 Aug 2008 09:14:44 -0500
Subject: [Distutils] My first egg
In-Reply-To: <48A19226.3050603@mineway.de>
References: <48A19226.3050603@mineway.de>
Message-ID: <48A19AD4.4020006@mail.utexas.edu>

Hi Uwe,

Do you mean console scripts or just example files?  If you set the 
'include_package_data' argument to True, all of the data files that are 
under version control will be included in your egg.  If you want to have 
more control over what goes in your egg and where they get put, you can 
use the 'data_files' argument, which is a list of tuples.  The first 
item in the tuple is the relative path inside the egg where you want 
your data to be placed.  The second item is a string, or a list of 
strings, which are paths relative to the root of your source tree for 
the files that you want to be placed in the destination you specified in 
the first item of the tuple.  Here is a simple example:

If your source tree looks like this:

setup.py
README.txt
examples/
    example1.py
    data1.dat
mypkg/
    __init__.py
    mypkg.py

And your 'data_files' argument was this:

data_files = [('', 'README.txt'),
              ('mypkg/examples', 'examples/*.*')]

Your egg structure should look like this:

mypkg-1.0.0-py2.5.egg/
    mypkg/
        examples/
            example1.py
            data1.dat 
        __init__.py
        mypkg.py
    README.txt
    

You can also use a glob for the second item in the tuple.

-- Chris Galvan

Uwe Schmitt wrote:
> Hi,
>
> I just finished my first egg, but have a question:
> How can I distribute example scripts for my
> package ???
>
> Greetings, Uwe
>


From cgalvan at mail.utexas.edu  Tue Aug 12 16:20:50 2008
From: cgalvan at mail.utexas.edu (Chris Galvan)
Date: Tue, 12 Aug 2008 09:20:50 -0500
Subject: [Distutils] My first egg
In-Reply-To: <48A19AD4.4020006@mail.utexas.edu>
References: <48A19226.3050603@mineway.de> <48A19AD4.4020006@mail.utexas.edu>
Message-ID: <48A19C42.7080800@mail.utexas.edu>

Oops, somehow the formatting I did on the egg structure got messed up.  
Here is what it's REALLY supposed to look like :)

mypkg-1.0.0-py2.5.egg/
    mypkg/
        examples/
            example1.py
            data1.dat
        __init__.py
        mypkg.py
    README.txt

-- Chris Galvan

Chris Galvan wrote:
> Hi Uwe,
>
> Do you mean console scripts or just example files?  If you set the 
> 'include_package_data' argument to True, all of the data files that 
> are under version control will be included in your egg.  If you want 
> to have more control over what goes in your egg and where they get 
> put, you can use the 'data_files' argument, which is a list of 
> tuples.  The first item in the tuple is the relative path inside the 
> egg where you want your data to be placed.  The second item is a 
> string, or a list of strings, which are paths relative to the root of 
> your source tree for the files that you want to be placed in the 
> destination you specified in the first item of the tuple.  Here is a 
> simple example:
>
> If your source tree looks like this:
>
> setup.py
> README.txt
> examples/
>    example1.py
>    data1.dat
> mypkg/
>    __init__.py
>    mypkg.py
>
> And your 'data_files' argument was this:
>
> data_files = [('', 'README.txt'),
>              ('mypkg/examples', 'examples/*.*')]
>
> Your egg structure should look like this:
>
> mypkg-1.0.0-py2.5.egg/
>    mypkg/
>        examples/
>            example1.py
>            data1.dat        __init__.py
>        mypkg.py
>    README.txt
>   
> You can also use a glob for the second item in the tuple.
>
> -- Chris Galvan
>
> Uwe Schmitt wrote:
>> Hi,
>>
>> I just finished my first egg, but have a question:
>> How can I distribute example scripts for my
>> package ???
>>
>> Greetings, Uwe
>>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>


From ziade.tarek at gmail.com  Tue Aug 12 16:22:13 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 12 Aug 2008 16:22:13 +0200
Subject: [Distutils] specify available build commands
In-Reply-To: <ead057790808120704q5c82ca6apa21e4d7fd3b169cc@mail.gmail.com>
References: <ead057790808120704q5c82ca6apa21e4d7fd3b169cc@mail.gmail.com>
Message-ID: <94bdd2610808120722j6952c091qa3258774b5b41285@mail.gmail.com>

On Tue, Aug 12, 2008 at 4:04 PM, chris <cdcasey at gmail.com> wrote:

> Is there a way in distutils / setuptools to list the available build
> commands via porperty or function?


commands usually calls other commands (bdist for instance calls build)

you can get a list of commands with:

$ python setup.py --help-commands

but i don't think you can list the underlying commands. The only
way is to look into the code of each commands.

>
>
> Specifically, I want to be able to add a configuration and build some
> classes only if one of these commands is specified.


what are you trying to do precisely ?

>
>
> python setup.py build <----- confuguration added
> python setup.py sdist bdist_egg <----- confuguration added


you are building two distributions here, one source (.tar.gz) and one binary
(.egg)
look into your dist/ folder.


>
> python setup.py sdist <----- confuguration not added
>
> Maybe there's a better way to do it.
>






> -Chris
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080812/253fe969/attachment.htm>

From fadhley.salim at uk.calyon.com  Tue Aug 12 16:46:49 2008
From: fadhley.salim at uk.calyon.com (Fadhley Salim)
Date: Tue, 12 Aug 2008 15:46:49 +0100
Subject: [Distutils] Distutils / Setuptools on Windows: Can we use local or
	UNC filesystems as an argument to --find-links
Message-ID: <7F347D91614EBC48AA7540A2A76D3BB201EC498C@MXCU10MX1.MSX.CIB>

A project I'm working on requires a Python egg to be deployed to a
remote location which (because of a security configuration outside my
control) denies users access to the web-servers we use to load eggs from
the office I work. 

I've determined that the security at this location allows users access
to Windows networked file-systems. It has been proposed that rather than
creating a web-repository for python eggs we store these on a local
file-server. But from what I can tell the easy_install utility can ONLY
load it's eggs from web-servers. 

Has anybody had any luck using the --find_options argument to
easy_install with a local folder (e.g. on a Windows C: Drive) or a
network folder, for example 

easy_install --find-links="http://server/egs" myegg==1.0.1 
( that sort of thing works fine )

but what about: 
easy_install --find-links="c:\myeggs\" myegg==1.0.1 

or even: 
easy_install --find-links="file:///c:/myeggs" myegg==1.01 

and with a UNC path:
easy_install --find-links="file://///myserver/webapps/eggs/" myegg==1.01

If (as I suspect) easy_install cannot support anything other than a
direct-http set-up is there a way for me to simply modify the code for
easy_install to do this? Furthermore, since we like to be up to date I
dont want to run a permanently forked version of setuptools - can we
submit any changes back to the project so we do not have to be
permanently forked?

Thanks
-------------- next part --------------
This email does not create a legal relationship between any member of the 
Cr?dit Agricole group and the recipient or constitute investment advice. 
The content of this email should not be copied or disclosed (in whole or 
part) to any other person. It may contain information which is 
confidential, privileged or otherwise protected from disclosure. If you 
are not the intended recipient, you should notify us and delete it from 
your system. Emails may be monitored, are not secure and may be amended, 
destroyed or contain viruses and in communicating with us such conditions 
are accepted. Any content which does not relate to business matters is not 
endorsed by us.

Calyon is authorised by the Commission Bancaire in France and regulated by 
the Financial Services Authority for the conduct of business in the 
United Kingdom. Calyon is incorporated in France with limited liability 
and registered in England & Wales. Registration number: FC008194. 
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.


From pje at telecommunity.com  Tue Aug 12 17:04:38 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 12 Aug 2008 11:04:38 -0400
Subject: [Distutils] My first egg
In-Reply-To: <48A19226.3050603@mineway.de>
References: <48A19226.3050603@mineway.de>
Message-ID: <20080812150356.BC2CB3A4093@sparrow.telecommunity.com>

At 03:37 PM 8/12/2008 +0200, Uwe Schmitt wrote:
>Hi,
>
>I just finished my first egg, but have a question:
>How can I distribute example scripts for my
>package ???

In your source distribution, with your documentation.  Eggs are a 
deployment format for code and data, not a distribution format for 
source, docs, and examples.


From ziade.tarek at gmail.com  Tue Aug 12 17:04:40 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 12 Aug 2008 17:04:40 +0200
Subject: [Distutils] setuptools tracker "needpatch" keyword, tests, etc.
In-Reply-To: <20080808162735.A533D3A4093@sparrow.telecommunity.com>
References: <20080808151935.21BEC3A4093@sparrow.telecommunity.com>
	<489C6728.4010003@mail.utexas.edu>
	<20080808162735.A533D3A4093@sparrow.telecommunity.com>
Message-ID: <94bdd2610808120804m3bd9ff09t9d8a8fdea6c99433@mail.gmail.com>

On Fri, Aug 8, 2008 at 6:28 PM, Phillip J. Eby <pje at telecommunity.com>wrote:

> ...
>>
>>
>>
>> https://code.launchpad.net/~setuptools/setuptools-test/main<https://code.launchpad.net/%7Esetuptools/setuptools-test/main>
>>
>
> My initial reaction is that it's off to a good start, but the tests
> themselves seem rather shallow; more like "smoke tests" (i.e., turn it on
> and see if smoke comes out) than functional tests.


Right, they are not detailed at all at this point

>
>
> I'm thinking it might help to use the setuptools.sandbox facility to log
> files created, deleted, modified, etc. by the process.  That would probably
> be a better test of what has/hasn't been done than using ellipses on the
> logs, which is order-dependent as well as having the ability to skip lines
> where the wrong thing is being done, etc.  The way things are being done
> now, they probably won't be able to test some of the things that are most
> likely to break (i.e., the complexities of easy_install).
>
> (Probably in order to do that I'll need to add a new sandboxing class that
> creates a "mock" filesystem and allows before/after expectations to be set.)



Here's a proposal that could be done in a new 'test' sprint I guess :

- add something in the sandbox to record what is being done underneath
(using for example what Ian has suggested - ScriptTest)
- change our doctests so they actually use the recorded info : files
created, removed, modified + return code maybe (but not the stdout which
vary too much from one system to another)

At least Chris Galvan and I are interested in helping in this.

Tarek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080812/6c4b0596/attachment.htm>

From pje at telecommunity.com  Tue Aug 12 17:14:57 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 12 Aug 2008 11:14:57 -0400
Subject: [Distutils] Distutils / Setuptools on Windows: Can we use local
 or UNC filesystems as an argument to --find-links
In-Reply-To: <7F347D91614EBC48AA7540A2A76D3BB201EC498C@MXCU10MX1.MSX.CIB
 >
References: <7F347D91614EBC48AA7540A2A76D3BB201EC498C@MXCU10MX1.MSX.CIB>
Message-ID: <20080812151404.D2A9C3A4093@sparrow.telecommunity.com>

At 03:46 PM 8/12/2008 +0100, Fadhley Salim wrote:
>Has anybody had any luck using the --find_options argument to
>easy_install with a local folder (e.g. on a Windows C: Drive) or a
>network folder, for example
>
>easy_install --find-links="http://server/egs" myegg==1.0.1
>( that sort of thing works fine )

So should this:

>easy_install --find-links="c:\myeggs\" myegg==1.0.1

The file:// urls can work too, but they work differently than just 
using a directory filename; they'll be checked at a later stage of 
processing.  And of course, they're harder to get right.  :)


From cdcasey at gmail.com  Tue Aug 12 17:38:26 2008
From: cdcasey at gmail.com (chris)
Date: Tue, 12 Aug 2008 10:38:26 -0500
Subject: [Distutils] specify available build commands
In-Reply-To: <ead057790808120837h3764a36enaf32f15131dbd0c8@mail.gmail.com>
References: <ead057790808120704q5c82ca6apa21e4d7fd3b169cc@mail.gmail.com>
	<94bdd2610808120722j6952c091qa3258774b5b41285@mail.gmail.com>
	<ead057790808120837h3764a36enaf32f15131dbd0c8@mail.gmail.com>
Message-ID: <ead057790808120838g73660205y4ab9ae169216473e@mail.gmail.com>

>>
>> Specifically, I want to be able to add a configuration and build some
>> classes only if one of these commands is specified.
>
> what are you trying to do precisely ?
>>
In a setup.py, there's a method that builds some classes and puts them
in a zip file. Then there's a line

config.add_data_files(this_method)

The method doesn't need to be called when only a source distribution
is being created. I was hoping there might be a way to switch this
config line off if there's no need for it, or maybe only switch it on
when it is needed (something beyond using sys.argv).

From fadhley.salim at uk.calyon.com  Tue Aug 12 17:41:01 2008
From: fadhley.salim at uk.calyon.com (Fadhley Salim)
Date: Tue, 12 Aug 2008 16:41:01 +0100
Subject: [Distutils] Distutils / Setuptools on Windows: Can we use local
	or UNC filesystems as an argument to --find-links
References: <7F347D91614EBC48AA7540A2A76D3BB201EC498C@MXCU10MX1.MSX.CIB>
	<20080812151404.D2A9C3A4093@sparrow.telecommunity.com>
Message-ID: <7F347D91614EBC48AA7540A2A76D3BB201EC498E@MXCU10MX1.MSX.CIB>

What about using a network folder, e.g. a UNC path? Were you able to get
such a thing working ever? 

-----Original Message-----
From: Phillip J. Eby [mailto:pje at telecommunity.com] 
Sent: 12 August 2008 16:15
To: Salim, Fadhley (CALYON); distutils-sig at python.org
Subject: Re: [Distutils] Distutils / Setuptools on Windows: Can we use
local or UNC filesystems as an argument to --find-links

At 03:46 PM 8/12/2008 +0100, Fadhley Salim wrote:
>Has anybody had any luck using the --find_options argument to 
>easy_install with a local folder (e.g. on a Windows C: Drive) or a 
>network folder, for example
>
>easy_install --find-links="http://server/egs" myegg==1.0.1 ( that sort 
>of thing works fine )

So should this:

>easy_install --find-links="c:\myeggs\" myegg==1.0.1

The file:// urls can work too, but they work differently than just using
a directory filename; they'll be checked at a later stage of processing.
And of course, they're harder to get right.  :)

-------------- next part --------------
This email does not create a legal relationship between any member of the 
Cr?dit Agricole group and the recipient or constitute investment advice. 
The content of this email should not be copied or disclosed (in whole or 
part) to any other person. It may contain information which is 
confidential, privileged or otherwise protected from disclosure. If you 
are not the intended recipient, you should notify us and delete it from 
your system. Emails may be monitored, are not secure and may be amended, 
destroyed or contain viruses and in communicating with us such conditions 
are accepted. Any content which does not relate to business matters is not 
endorsed by us.

Calyon is authorised by the Commission Bancaire in France and regulated by 
the Financial Services Authority for the conduct of business in the 
United Kingdom. Calyon is incorporated in France with limited liability 
and registered in England & Wales. Registration number: FC008194. 
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.


From ziade.tarek at gmail.com  Tue Aug 12 17:55:38 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 12 Aug 2008 17:55:38 +0200
Subject: [Distutils] specify available build commands
In-Reply-To: <ead057790808120838g73660205y4ab9ae169216473e@mail.gmail.com>
References: <ead057790808120704q5c82ca6apa21e4d7fd3b169cc@mail.gmail.com>
	<94bdd2610808120722j6952c091qa3258774b5b41285@mail.gmail.com>
	<ead057790808120837h3764a36enaf32f15131dbd0c8@mail.gmail.com>
	<ead057790808120838g73660205y4ab9ae169216473e@mail.gmail.com>
Message-ID: <94bdd2610808120855w68468dc8td29d257368c35a93@mail.gmail.com>

On Tue, Aug 12, 2008 at 5:38 PM, chris <cdcasey at gmail.com> wrote:

> >>
> >> Specifically, I want to be able to add a configuration and build some
> >> classes only if one of these commands is specified.
> >
> > what are you trying to do precisely ?
> >>
> In a setup.py, there's a method that builds some classes and puts them
> in a zip file. Then there's a line
>
> config.add_data_files(this_method)
>
> The method doesn't need to be called when only a source distribution
> is being created. I was hoping there might be a way to switch this
> config line off if there's no need for it, or maybe only switch it on
> when it is needed (something beyond using sys.argv).
>

So you create a specific zip file on the fly, with some things in it, that
is added in your source tree ?

Maybe you could create a specific source distribution command, that runs
your code then call sdist

Tarek


> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080812/09d079e1/attachment.htm>

From pje at telecommunity.com  Tue Aug 12 18:16:45 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 12 Aug 2008 12:16:45 -0400
Subject: [Distutils] Distutils / Setuptools on Windows: Can we use local
 or UNC filesystems as an argument to --find-links
In-Reply-To: <7F347D91614EBC48AA7540A2A76D3BB201EC498E@MXCU10MX1.MSX.CIB
 >
References: <7F347D91614EBC48AA7540A2A76D3BB201EC498C@MXCU10MX1.MSX.CIB>
	<20080812151404.D2A9C3A4093@sparrow.telecommunity.com>
	<7F347D91614EBC48AA7540A2A76D3BB201EC498E@MXCU10MX1.MSX.CIB>
Message-ID: <20080812161553.B396F3A4093@sparrow.telecommunity.com>

At 04:41 PM 8/12/2008 +0100, Fadhley Salim wrote:
>What about using a network folder, e.g. a UNC path? Were you able to get
>such a thing working ever?

I've heard of people using network folders; I'm not sure I've 
personally tried a UNC path.  Keep in mind that command-line 
quoting/escaping can foul up your backslashes, though, so I would 
suggest trying using '/' in place of '\' in your command line.  That 
is, '//server/share' instead of '\\server\share'.


>-----Original Message-----
>From: Phillip J. Eby [mailto:pje at telecommunity.com]
>Sent: 12 August 2008 16:15
>To: Salim, Fadhley (CALYON); distutils-sig at python.org
>Subject: Re: [Distutils] Distutils / Setuptools on Windows: Can we use
>local or UNC filesystems as an argument to --find-links
>
>At 03:46 PM 8/12/2008 +0100, Fadhley Salim wrote:
> >Has anybody had any luck using the --find_options argument to
> >easy_install with a local folder (e.g. on a Windows C: Drive) or a
> >network folder, for example
> >
> >easy_install --find-links="http://server/egs" myegg==1.0.1 ( that sort
> >of thing works fine )
>
>So should this:
>
> >easy_install --find-links="c:\myeggs\" myegg==1.0.1
>
>The file:// urls can work too, but they work differently than just using
>a directory filename; they'll be checked at a later stage of processing.
>And of course, they're harder to get right.  :)


From fadhley.salim at uk.calyon.com  Tue Aug 12 19:23:15 2008
From: fadhley.salim at uk.calyon.com (Fadhley Salim)
Date: Tue, 12 Aug 2008 18:23:15 +0100
Subject: [Distutils] Distutils / Setuptools on Windows: Can we use local
	or UNC filesystems as an argument to --find-links
References: <7F347D91614EBC48AA7540A2A76D3BB201EC498C@MXCU10MX1.MSX.CIB>
	<20080812151404.D2A9C3A4093@sparrow.telecommunity.com>
	<7F347D91614EBC48AA7540A2A76D3BB201EC498E@MXCU10MX1.MSX.CIB>
	<20080812161553.B396F3A4093@sparrow.telecommunity.com>
Message-ID: <7F347D91614EBC48AA7540A2A76D3BB201EC498F@MXCU10MX1.MSX.CIB>

Phillip,

Thanks for your help - still no go!

Any time I give it a web URL (e.g. http://something) it works fine. If I
give it something else, it seems to get confused - there's no evidence
that it's even looking at my folder. 

I'm trying to do something like this:

easy_install -m calyon-tools==1.0-r2008-0630-trunk-3968
--find-packages="//sald441/webapps/eggs/tools_egg/"

The output is:

------------------------
interrupted
Searching for calyon-tools==1.0-r2008-06-30-trunk-3968
Reading http://pypi.python.org/simple/calyon-tools/
Download error: (10060, 'Operation timed out') -- Some packages may not
be found
!
Reading http://pypi.python.org/simple/calyon-tools/
Download error: (10060, 'Operation timed out') -- Some packages may not
be found
!
Couldn't retrieve index page for 'calyon-tools'
Scanning index of all packages (this may take a while)
Reading http://pypi.python.org/simple/
Download error: (10060, 'Operation timed out') -- Some packages may not
be found
!
No local packages or download links found for
calyon-tools==1.0-r2008-06-30-trun
k-3968
error: Could not find suitable distribution for
Requirement.parse('calyon-tools=
=1.0-r2008-06-30-trunk-3968')
------------------------

But just to confirm the folder definitely can be read from within
python:

>>> import os
>>> os.listdir(r"//sald441/webapps/eggs/tools_egg/")
['calyon_tools-1.0_r2008_06_30_trunk_3968-py2.4.egg']
>>>

Furthermore I can easy install that file explicitly - it definitely does
install:

D:\WORKSP~1\PYTHON~2\calyon_egg\dist>easy_install -m
\\sald441\webapps\eggs\tool
s_egg\calyon_tools-1.0_r2008_06_30_trunk_3968-py2.4.egg
Processing calyon_tools-1.0_r2008_06_30_trunk_3968-py2.4.egg
Copying calyon_tools-1.0_r2008_06_30_trunk_3968-py2.4.egg to
d:\python24\lib\sit
e-packages
Installing start_inspector.bat script to d:\Python24\Scripts
Installing runbatch-script.py script to d:\Python24\Scripts
Installing runbatch.exe script to d:\Python24\Scripts
Installing make_launchers-script.py script to d:\Python24\Scripts


Sal

-----Original Message-----
From: Phillip J. Eby [mailto:pje at telecommunity.com] 
Sent: 12 August 2008 17:17
To: Salim, Fadhley (CALYON); distutils-sig at python.org
Subject: RE: [Distutils] Distutils / Setuptools on Windows: Can we use
local or UNC filesystems as an argument to --find-links

At 04:41 PM 8/12/2008 +0100, Fadhley Salim wrote:
>What about using a network folder, e.g. a UNC path? Were you able to 
>get such a thing working ever?

I've heard of people using network folders; I'm not sure I've personally
tried a UNC path.  Keep in mind that command-line quoting/escaping can
foul up your backslashes, though, so I would suggest trying using '/' in
place of '\' in your command line.  That is, '//server/share' instead of
'\\server\share'.


>-----Original Message-----
>From: Phillip J. Eby [mailto:pje at telecommunity.com]
>Sent: 12 August 2008 16:15
>To: Salim, Fadhley (CALYON); distutils-sig at python.org
>Subject: Re: [Distutils] Distutils / Setuptools on Windows: Can we use 
>local or UNC filesystems as an argument to --find-links
>
>At 03:46 PM 8/12/2008 +0100, Fadhley Salim wrote:
> >Has anybody had any luck using the --find_options argument to 
> >easy_install with a local folder (e.g. on a Windows C: Drive) or a 
> >network folder, for example
> >
> >easy_install --find-links="http://server/egs" myegg==1.0.1 ( that 
> >sort of thing works fine )
>
>So should this:
>
> >easy_install --find-links="c:\myeggs\" myegg==1.0.1
>
>The file:// urls can work too, but they work differently than just 
>using a directory filename; they'll be checked at a later stage of
processing.
>And of course, they're harder to get right.  :)

-------------- next part --------------
This email does not create a legal relationship between any member of the 
Cr?dit Agricole group and the recipient or constitute investment advice. 
The content of this email should not be copied or disclosed (in whole or 
part) to any other person. It may contain information which is 
confidential, privileged or otherwise protected from disclosure. If you 
are not the intended recipient, you should notify us and delete it from 
your system. Emails may be monitored, are not secure and may be amended, 
destroyed or contain viruses and in communicating with us such conditions 
are accepted. Any content which does not relate to business matters is not 
endorsed by us.

Calyon is authorised by the Commission Bancaire in France and regulated by 
the Financial Services Authority for the conduct of business in the 
United Kingdom. Calyon is incorporated in France with limited liability 
and registered in England & Wales. Registration number: FC008194. 
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.


From pje at telecommunity.com  Tue Aug 12 20:50:49 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 12 Aug 2008 14:50:49 -0400
Subject: [Distutils] Distutils / Setuptools on Windows: Can we use local
 or UNC filesystems as an argument to --find-links
In-Reply-To: <7F347D91614EBC48AA7540A2A76D3BB201EC498F@MXCU10MX1.MSX.CIB
 >
References: <7F347D91614EBC48AA7540A2A76D3BB201EC498C@MXCU10MX1.MSX.CIB>
	<20080812151404.D2A9C3A4093@sparrow.telecommunity.com>
	<7F347D91614EBC48AA7540A2A76D3BB201EC498E@MXCU10MX1.MSX.CIB>
	<20080812161553.B396F3A4093@sparrow.telecommunity.com>
	<7F347D91614EBC48AA7540A2A76D3BB201EC498F@MXCU10MX1.MSX.CIB>
Message-ID: <20080812184957.ECEDF3A403D@sparrow.telecommunity.com>

At 06:23 PM 8/12/2008 +0100, Fadhley Salim wrote:
>Phillip,
>
>Thanks for your help - still no go!
>
>Any time I give it a web URL (e.g. http://something) it works fine. If I
>give it something else, it seems to get confused - there's no evidence
>that it's even looking at my folder.
>
>I'm trying to do something like this:
>
>easy_install -m calyon-tools==1.0-r2008-0630-trunk-3968
>--find-packages="//sald441/webapps/eggs/tools_egg/"

There is no such option as "--find-packages"; it's "-f" or 
"--find-links".  Also, you should not include a trailing '/' or '\' 
when specifying file paths.

If you want to check whether a directory is being processed, increase 
the verbosity of setuptools output to at least '-vv'; then you should 
see a series of "Found:" lines appear listing the contents of the 
target directory.


From chris at simplistix.co.uk  Tue Aug 12 21:14:30 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 12 Aug 2008 20:14:30 +0100
Subject: [Distutils] [buildout] where does the demo egg come from
	in	tests?
In-Reply-To: <g7fgmv$flm$1@ger.gmane.org>
References: <4899DBE5.3080400@simplistix.co.uk> <g7fgmv$flm$1@ger.gmane.org>
Message-ID: <48A1E116.2040009@simplistix.co.uk>

Maurits van Rees wrote:
> If I have followed the code trail correctly:
> 
> - zc/recipe/egg/tests.py has a setUp(test) function.
> 
> - This calls 'zc.buildout.tests.easy_install_SetUp(test)'.
> 
> - That function calls create_sample_eggs from that same tests.py file
>   in zc.buildout.
> 
> - And that method creates some eggs on the fly.

Indeed, the code is in here:

http://svn.zope.org/zc.buildout/trunk/src/zc/buildout/tests.py?rev=88919&view=auto

search for "def create_sample_eggs".

As far as documentation goes, that's about as unhelpful and opaque as it 
gets :-(

Why on earth is this stuff obfuscated in this way?

Chris

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

From chris at simplistix.co.uk  Tue Aug 12 21:16:03 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 12 Aug 2008 20:16:03 +0100
Subject: [Distutils] [buildout] where does the demo egg come from in
	tests?
In-Reply-To: <37E05B3A-F8A9-4E50-A17B-E19608F605B4@zope.com>
References: <4899DBE5.3080400@simplistix.co.uk>
	<37E05B3A-F8A9-4E50-A17B-E19608F605B4@zope.com>
Message-ID: <48A1E173.9090601@simplistix.co.uk>

Jim Fulton wrote:
> 
> See:
> 
> http://peak.telecommunity.com/DevCenter/setuptools#automatic-script-creation 

Thanks, but that demo egg is referred to from a lot of places. The way 
it's created means there's zero chance for someone trying to see how the 
  structure of the egg relates to the docs in zc.recipe.egg...

cheers,

Chris

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

From chris at simplistix.co.uk  Tue Aug 12 22:18:31 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 12 Aug 2008 21:18:31 +0100
Subject: [Distutils] [buildout] weird behaviour of first buildout on
	windows...
In-Reply-To: <C92F00F6-93D3-4D85-A784-1FA0B428DFFC@zope.com>
References: <48982621.6010802@simplistix.co.uk>
	<C92F00F6-93D3-4D85-A784-1FA0B428DFFC@zope.com>
Message-ID: <48A1F017.8070808@simplistix.co.uk>

Jim Fulton wrote:
> I'll look into this.

Thanks, if you fancy more windows-specific weirdness, zope.testrunner's 
tests also do weird things on Windows:

http://mail.zope.org/pipermail/zope-dev/2008-August/032849.html

cheers,

Chris

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

From chris at simplistix.co.uk  Tue Aug 12 22:20:33 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 12 Aug 2008 21:20:33 +0100
Subject: [Distutils] [zc.buildout] test failures on trunk
Message-ID: <48A1F091.5090000@simplistix.co.uk>

Hi All,

I saw lots of failures on Windows, but I guess that's 'cos I need to 
have a C-compiler, right?

Anyway, even on Linux there were still these failures with python 2.4.5:

$ bin/test
Running zope.testing.testrunner.layer.UnitTests tests:
   Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
zip_safe flag not set; analyzing archive contents...
zip_safe flag not set; analyzing archive contents...
zip_safe flag not set; analyzing archive contents...
zip_safe flag not set; analyzing archive contents...
zip_safe flag not set; analyzing archive contents...
zip_safe flag not set; analyzing archive contents...


Failure in test test_bootstrap_py (zc.buildout.tests)
Failed doctest test for zc.buildout.tests.test_bootstrap_py
   File "/home/chris/zc.buildout/src/zc/buildout/tests.py", line 581, in 
test_bootstrap_py

----------------------------------------------------------------------
File "/home/chris/zc.buildout/src/zc/buildout/tests.py", line 592, in 
zc.buildout.tests.test_bootstrap_py
Failed example:
     print system(zc.buildout.easy_install._safe_arg(sys.executable)+' '+
                  'bootstrap.py'), # doctest: +ELLIPSIS
Expected:
     Downloading ...
     Generated script '/sample/bin/buildout'.
Got:
     Creating directory '/sample/bin'.
     Creating directory '/sample/parts'.
     Creating directory '/sample/eggs'.
     Creating directory '/sample/develop-eggs'.
     Generated script '/sample/bin/buildout'.
----------------------------------------------------------------------
File "/home/chris/zc.buildout/src/zc/buildout/tests.py", line 609, in 
zc.buildout.tests.test_bootstrap_py
Failed example:
     ls(sample_buildout, 'eggs')
Expected:
     -  setuptools.eggpyN.N.egg
     d  zc.buildout.eggpyN.N.egg
Got:
     d  setuptools.eggpyN.N.egg
     d  zc.buildout.eggpyN.N.egg

zip_safe flag not set; analyzing archive contents...
   Ran 353 tests with 1 failures and 0 errors in 4 minutes 22.881 seconds.
Tearing down left over layers:
   Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.

cheers,

Chris

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

From jim at zope.com  Tue Aug 12 23:24:53 2008
From: jim at zope.com (Jim Fulton)
Date: Tue, 12 Aug 2008 17:24:53 -0400
Subject: [Distutils] [zc.buildout] test failures on trunk
In-Reply-To: <48A1F091.5090000@simplistix.co.uk>
References: <48A1F091.5090000@simplistix.co.uk>
Message-ID: <69F4F6C1-C37F-4EEC-A5D4-C086E43BB707@zope.com>


On Aug 12, 2008, at 4:20 PM, Chris Withers wrote:

> Hi All,
>
> I saw lots of failures on Windows, but I guess that's 'cos I need to  
> have a C-compiler, right?

Yup.

> Anyway, even on Linux there were still these failures with python  
> 2.4.5:
>
> $ bin/test
> Running zope.testing.testrunner.layer.UnitTests tests:
>  Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
> zip_safe flag not set; analyzing archive contents...
> zip_safe flag not set; analyzing archive contents...
> zip_safe flag not set; analyzing archive contents...
> zip_safe flag not set; analyzing archive contents...
> zip_safe flag not set; analyzing archive contents...
> zip_safe flag not set; analyzing archive contents...
>
>
> Failure in test test_bootstrap_py (zc.buildout.tests)
> Failed doctest test for zc.buildout.tests.test_bootstrap_py
>  File "/home/chris/zc.buildout/src/zc/buildout/tests.py", line 581,  
> in test_bootstrap_py
>
> ----------------------------------------------------------------------
> File "/home/chris/zc.buildout/src/zc/buildout/tests.py", line 592,  
> in zc.buildout.tests.test_bootstrap_py
> Failed example:
>    print system(zc.buildout.easy_install._safe_arg(sys.executable)+'  
> '+
>                 'bootstrap.py'), # doctest: +ELLIPSIS
> Expected:
>    Downloading ...
>    Generated script '/sample/bin/buildout'.
> Got:
>    Creating directory '/sample/bin'.
>    Creating directory '/sample/parts'.
>    Creating directory '/sample/eggs'.
>    Creating directory '/sample/develop-eggs'.
>    Generated script '/sample/bin/buildout'.
> ----------------------------------------------------------------------
> File "/home/chris/zc.buildout/src/zc/buildout/tests.py", line 609,  
> in zc.buildout.tests.test_bootstrap_py
> Failed example:
>    ls(sample_buildout, 'eggs')
> Expected:
>    -  setuptools.eggpyN.N.egg
>    d  zc.buildout.eggpyN.N.egg
> Got:
>    d  setuptools.eggpyN.N.egg
>    d  zc.buildout.eggpyN.N.egg
>
> zip_safe flag not set; analyzing archive contents...
>  Ran 353 tests with 1 failures and 0 errors in 4 minutes 22.881  
> seconds.
> Tearing down left over layers:
>  Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.


I'm not seeing any failures on Linux or Windows.

Jim

--
Jim Fulton
Zope Corporation



From philipp at weitershausen.de  Wed Aug 13 00:50:47 2008
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Wed, 13 Aug 2008 00:50:47 +0200
Subject: [Distutils] [zc.buildout] test failures on trunk
In-Reply-To: <48A1F091.5090000@simplistix.co.uk>
References: <48A1F091.5090000@simplistix.co.uk>
Message-ID: <48A213C7.2060600@weitershausen.de>

Chris Withers wrote:
> I saw lots of failures on Windows, but I guess that's 'cos I need to 
> have a C-compiler, right?

This can be fixed easily: 
http://philikon.wordpress.com/2008/08/07/cheap-binary-windows-eggs/

From fadhley.salim at uk.calyon.com  Wed Aug 13 10:30:38 2008
From: fadhley.salim at uk.calyon.com (Fadhley Salim)
Date: Wed, 13 Aug 2008 09:30:38 +0100
Subject: [Distutils] Distutils / Setuptools on Windows: Can we use local
	or UNC filesystems as an argument to --find-links
References: <7F347D91614EBC48AA7540A2A76D3BB201EC498C@MXCU10MX1.MSX.CIB>
	<20080812151404.D2A9C3A4093@sparrow.telecommunity.com>
	<7F347D91614EBC48AA7540A2A76D3BB201EC498E@MXCU10MX1.MSX.CIB>
	<20080812161553.B396F3A4093@sparrow.telecommunity.com>
	<7F347D91614EBC48AA7540A2A76D3BB201EC498F@MXCU10MX1.MSX.CIB>
	<20080812184957.ECEDF3A403D@sparrow.telecommunity.com>
Message-ID: <7F347D91614EBC48AA7540A2A76D3BB201EC4990@MXCU10MX1.MSX.CIB>

Silly, silly me!

Yes, on the occasion that I cut & pasted I got the command-line argument
name wrong. 

Even correcting that command-line the feature still does not seem to
work as expected on Windows. Would you be able to provide an example
syntax that works on this platform? Has anybody been able to confirm
that this feature works on Windows? Ideally I'd like to be able to use
both a local folder and also a netowrk folder specified by UNC path. 

Since I was having no luck with the command-line option I've been
experimenting with the config file:

[easy_install]
find_links=<space seperated list of links>

This works just fine every time I specify a web-url, but seems to fail
every time I specify anything else. That is entirely consistent with the
command-line behavior.  

I'm quite confused as to how I should correctly specify non-web URLs,
the documentation makes no mention of the right way to do it:

* Should paths be escaped or not? (I think no)
* Should paths have trailing slashes? (Phillip says no)
* UNIX "/" or Windows "\" style slashes?
* Use "file:" at the begining?

Thanks everybody!

-----Original Message-----
From: Phillip J. Eby [mailto:pje at telecommunity.com] 
Sent: 12 August 2008 19:51
To: Salim, Fadhley (CALYON); distutils-sig at python.org
Subject: RE: [Distutils] Distutils / Setuptools on Windows: Can we use
local or UNC filesystems as an argument to --find-links

At 06:23 PM 8/12/2008 +0100, Fadhley Salim wrote:
>Phillip,
>
>Thanks for your help - still no go!
>
>Any time I give it a web URL (e.g. http://something) it works fine. If 
>I give it something else, it seems to get confused - there's no 
>evidence that it's even looking at my folder.
>
>I'm trying to do something like this:
>
>easy_install -m calyon-tools==1.0-r2008-0630-trunk-3968
>--find-packages="//sald441/webapps/eggs/tools_egg/"

There is no such option as "--find-packages"; it's "-f" or
"--find-links".  Also, you should not include a trailing '/' or '\' 
when specifying file paths.

If you want to check whether a directory is being processed, increase
the verbosity of setuptools output to at least '-vv'; then you should
see a series of "Found:" lines appear listing the contents of the target
directory.

-------------- next part --------------
This email does not create a legal relationship between any member of the 
Cr?dit Agricole group and the recipient or constitute investment advice. 
The content of this email should not be copied or disclosed (in whole or 
part) to any other person. It may contain information which is 
confidential, privileged or otherwise protected from disclosure. If you 
are not the intended recipient, you should notify us and delete it from 
your system. Emails may be monitored, are not secure and may be amended, 
destroyed or contain viruses and in communicating with us such conditions 
are accepted. Any content which does not relate to business matters is not 
endorsed by us.

Calyon is authorised by the Commission Bancaire in France and regulated by 
the Financial Services Authority for the conduct of business in the 
United Kingdom. Calyon is incorporated in France with limited liability 
and registered in England & Wales. Registration number: FC008194. 
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.


From chris at simplistix.co.uk  Wed Aug 13 11:05:01 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 13 Aug 2008 10:05:01 +0100
Subject: [Distutils] [zc.buildout] test failures on trunk
In-Reply-To: <69F4F6C1-C37F-4EEC-A5D4-C086E43BB707@zope.com>
References: <48A1F091.5090000@simplistix.co.uk>
	<69F4F6C1-C37F-4EEC-A5D4-C086E43BB707@zope.com>
Message-ID: <48A2A3BD.3030202@simplistix.co.uk>

Jim Fulton wrote:
>> $ bin/test
>> Running zope.testing.testrunner.layer.UnitTests tests:
>>  Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
>> zip_safe flag not set; analyzing archive contents...
>> zip_safe flag not set; analyzing archive contents...
>> zip_safe flag not set; analyzing archive contents...
>> zip_safe flag not set; analyzing archive contents...
>> zip_safe flag not set; analyzing archive contents...
>> zip_safe flag not set; analyzing archive contents...

Is the above output normal?

>> Failure in test test_bootstrap_py (zc.buildout.tests)
>> Failed doctest test for zc.buildout.tests.test_bootstrap_py
>>  File "/home/chris/zc.buildout/src/zc/buildout/tests.py", line 581, in 
>> test_bootstrap_py
>>
>> ----------------------------------------------------------------------
>> File "/home/chris/zc.buildout/src/zc/buildout/tests.py", line 592, in 
>> zc.buildout.tests.test_bootstrap_py
>> Failed example:
>>    print system(zc.buildout.easy_install._safe_arg(sys.executable)+' '+
>>                 'bootstrap.py'), # doctest: +ELLIPSIS
>> Expected:
>>    Downloading ...
>>    Generated script '/sample/bin/buildout'.
>> Got:
>>    Creating directory '/sample/bin'.
>>    Creating directory '/sample/parts'.
>>    Creating directory '/sample/eggs'.
>>    Creating directory '/sample/develop-eggs'.
>>    Generated script '/sample/bin/buildout'.
>> ----------------------------------------------------------------------
>> File "/home/chris/zc.buildout/src/zc/buildout/tests.py", line 609, in 
>> zc.buildout.tests.test_bootstrap_py
>> Failed example:
>>    ls(sample_buildout, 'eggs')
>> Expected:
>>    -  setuptools.eggpyN.N.egg
>>    d  zc.buildout.eggpyN.N.egg
>> Got:
>>    d  setuptools.eggpyN.N.egg
>>    d  zc.buildout.eggpyN.N.egg
>>
>> zip_safe flag not set; analyzing archive contents...
>>  Ran 353 tests with 1 failures and 0 errors in 4 minutes 22.881 seconds.
>> Tearing down left over layers:
>>  Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
> 
> I'm not seeing any failures on Linux or Windows.

Well, this is on a fresh trunk checkout at r89787.

What version of python did you test with? I was using 2.4.5...

Other than that, I'm stumped, any ideas on the cause welcome...

cheers,

Chris

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

From chris at simplistix.co.uk  Wed Aug 13 11:22:58 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 13 Aug 2008 10:22:58 +0100
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
Message-ID: <48A2A7F2.8040402@simplistix.co.uk>

Hi All,

What I'd like to do at the start of the "Script generation" section was 
cat the setup.py of the demo egg to show the entry point where the demo 
eggs defines its script.

However, given that the demo egg is a binary egg, I can't decide what 
the best way to do this is. I'd thought of using the zipfile module to 
reach inside the egg, but I'm confused as to why -py2.3.egg files are 
specified in the test and work even though I'm running with python 2.4 
and there's no python 2.3 in sight?

Any ideas welcome...

cheers,

Chris

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

From chris at simplistix.co.uk  Wed Aug 13 13:23:50 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 13 Aug 2008 12:23:50 +0100
Subject: [Distutils] [buildout] looking for review of docs on find-links
Message-ID: <48A2C446.5080000@simplistix.co.uk>

Hi,

I just added some docs for the find-links option:

http://mail.zope.org/pipermail/checkins/2008-August/023822.html

I'm not 100% on the order of searching of locations specified in 
find-links and whether or not pypi is still searched.

Would be great if someone could have a look and let me know if I need to 
make any changes.

cheers,

Chris

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

From fadhley.salim at uk.calyon.com  Wed Aug 13 15:34:12 2008
From: fadhley.salim at uk.calyon.com (Fadhley Salim)
Date: Wed, 13 Aug 2008 14:34:12 +0100
Subject: [Distutils] Is it possible to stop easy_install from checking pypi
References: <48A2C446.5080000@simplistix.co.uk>
Message-ID: <7F347D91614EBC48AA7540A2A76D3BB201EC4992@MXCU10MX1.MSX.CIB>

If the packages cannot be found in the URLs that I specify in find-links
easy_install always checks pypi. 

Is there some way to prevent this? I'd like to ensure that pypi is never
checked.

Sal
-------------- next part --------------
This email does not create a legal relationship between any member of the 
Cr?dit Agricole group and the recipient or constitute investment advice. 
The content of this email should not be copied or disclosed (in whole or 
part) to any other person. It may contain information which is 
confidential, privileged or otherwise protected from disclosure. If you 
are not the intended recipient, you should notify us and delete it from 
your system. Emails may be monitored, are not secure and may be amended, 
destroyed or contain viruses and in communicating with us such conditions 
are accepted. Any content which does not relate to business matters is not 
endorsed by us.

Calyon is authorised by the Commission Bancaire in France and regulated by 
the Financial Services Authority for the conduct of business in the 
United Kingdom. Calyon is incorporated in France with limited liability 
and registered in England & Wales. Registration number: FC008194. 
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.


From ziade.tarek at gmail.com  Wed Aug 13 15:39:54 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 13 Aug 2008 15:39:54 +0200
Subject: [Distutils] Is it possible to stop easy_install from checking
	pypi
In-Reply-To: <7F347D91614EBC48AA7540A2A76D3BB201EC4992@MXCU10MX1.MSX.CIB>
References: <48A2C446.5080000@simplistix.co.uk>
	<7F347D91614EBC48AA7540A2A76D3BB201EC4992@MXCU10MX1.MSX.CIB>
Message-ID: <94bdd2610808130639r18d3cf17t9cbffb05cd62d95@mail.gmail.com>

On Wed, Aug 13, 2008 at 3:34 PM, Fadhley Salim
<fadhley.salim at uk.calyon.com>wrote:

> If the packages cannot be found in the URLs that I specify in find-links
> easy_install always checks pypi.
>
> Is there some way to prevent this? I'd like to ensure that pypi is never
> checked.


Hello

You can use the --allow-hosts option to filter out authorized sites

see :

http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-downloads-with-allow-hosts

Although, I think you might encouter a bug with links starting with file://

Regards
Tarek




>
>
> Sal
>
> This email does not create a legal relationship between any member of the
> Cr?dit Agricole group and the recipient or constitute investment advice.
> The content of this email should not be copied or disclosed (in whole or
> part) to any other person. It may contain information which is
> confidential, privileged or otherwise protected from disclosure. If you
> are not the intended recipient, you should notify us and delete it from
> your system. Emails may be monitored, are not secure and may be amended,
> destroyed or contain viruses and in communicating with us such conditions
> are accepted. Any content which does not relate to business matters is not
> endorsed by us.
>
> Calyon is authorised by the Commission Bancaire in France and regulated by
> the Financial Services Authority for the conduct of business in the
> United Kingdom. Calyon is incorporated in France with limited liability
> and registered in England & Wales. Registration number: FC008194.
> Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>


-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080813/ffb80b8a/attachment.htm>

From ziade.tarek at gmail.com  Wed Aug 13 15:43:03 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 13 Aug 2008 15:43:03 +0200
Subject: [Distutils] Is it possible to stop easy_install from checking
	pypi
In-Reply-To: <94bdd2610808130639r18d3cf17t9cbffb05cd62d95@mail.gmail.com>
References: <48A2C446.5080000@simplistix.co.uk>
	<7F347D91614EBC48AA7540A2A76D3BB201EC4992@MXCU10MX1.MSX.CIB>
	<94bdd2610808130639r18d3cf17t9cbffb05cd62d95@mail.gmail.com>
Message-ID: <94bdd2610808130643m81e3491ha8cca541a6017d13@mail.gmail.com>

On Wed, Aug 13, 2008 at 3:39 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

>
>
> On Wed, Aug 13, 2008 at 3:34 PM, Fadhley Salim <
> fadhley.salim at uk.calyon.com> wrote:
>
>> If the packages cannot be found in the URLs that I specify in find-links
>> easy_install always checks pypi.
>>
>> Is there some way to prevent this? I'd like to ensure that pypi is never
>> checked.
>
>
> Hello
>
> You can use the --allow-hosts option to filter out authorized sites
>
> see :
>
>
> http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-downloads-with-allow-hosts
>
> Although, I think you might encouter a bug with links starting with file://
>

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


>
> Regards
> Tarek
>
>
>
>
>>
>>
>> Sal
>>
>> This email does not create a legal relationship between any member of the
>> Cr?dit Agricole group and the recipient or constitute investment advice.
>> The content of this email should not be copied or disclosed (in whole or
>> part) to any other person. It may contain information which is
>> confidential, privileged or otherwise protected from disclosure. If you
>> are not the intended recipient, you should notify us and delete it from
>> your system. Emails may be monitored, are not secure and may be amended,
>> destroyed or contain viruses and in communicating with us such conditions
>> are accepted. Any content which does not relate to business matters is not
>> endorsed by us.
>>
>> Calyon is authorised by the Commission Bancaire in France and regulated by
>> the Financial Services Authority for the conduct of business in the
>> United Kingdom. Calyon is incorporated in France with limited liability
>> and registered in England & Wales. Registration number: FC008194.
>> Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.
>>
>>
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>>
>>
>
>
> --
> Tarek Ziad? | Association AfPy | www.afpy.org
> Blog FR | http://programmation-python.org
> Blog EN | http://tarekziade.wordpress.com/
>



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080813/20c0abbf/attachment.htm>

From jim at zope.com  Wed Aug 13 15:59:53 2008
From: jim at zope.com (Jim Fulton)
Date: Wed, 13 Aug 2008 09:59:53 -0400
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
In-Reply-To: <48A2A7F2.8040402@simplistix.co.uk>
References: <48A2A7F2.8040402@simplistix.co.uk>
Message-ID: <CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com>


On Aug 13, 2008, at 5:22 AM, Chris Withers wrote:

> Hi All,
>
> What I'd like to do at the start of the "Script generation" section  
> was cat the setup.py of the demo egg to show the entry point where  
> the demo eggs defines its script.
>
> However, given that the demo egg is a binary egg, I can't decide  
> what the best way to do this is.

We could just show the contents of setup.py or simply explain, perhaps  
in a footnote that the scripts are defined via entry points, giving a  
link to the setuptools documentation.



> I'd thought of using the zipfile module to reach inside the egg, but  
> I'm confused as to why -py2.3.egg files are specified in the test  
> and work even though I'm running with python 2.4 and there's no  
> python 2.3 in sight?

The examples have to show something, The tests have to be run with  
multiple versions of Python, since multiple versions of Python are  
supported.  An output normalizer takes care adjusting actual and  
expected output for the version of Python used at run time.

Jim

--
Jim Fulton
Zope Corporation



From fadhley.salim at uk.calyon.com  Wed Aug 13 16:20:50 2008
From: fadhley.salim at uk.calyon.com (Fadhley Salim)
Date: Wed, 13 Aug 2008 15:20:50 +0100
Subject: [Distutils] [buildout] looking for review of docs on find-links
References: <48A2C446.5080000@simplistix.co.uk>
Message-ID: <7F347D91614EBC48AA7540A2A76D3BB201EC4993@MXCU10MX1.MSX.CIB>

Chris,

Another suggestion for the doc:

It could describe the consequence of having --find-links on the command
line, plus find_links= in the distutils.cfg file. From what I can tell,
you should use one or the other but not both.

Sal 

-----Original Message-----
From: distutils-sig-bounces at python.org
[mailto:distutils-sig-bounces at python.org] On Behalf Of Chris Withers
Sent: 13 August 2008 12:24
To: distutils-sig at python.org
Subject: [Distutils] [buildout] looking for review of docs on find-links

Hi,

I just added some docs for the find-links option:

http://mail.zope.org/pipermail/checkins/2008-August/023822.html

I'm not 100% on the order of searching of locations specified in
find-links and whether or not pypi is still searched.

Would be great if someone could have a look and let me know if I need to
make any changes.

cheers,

Chris

--
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG at python.org
http://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
This email does not create a legal relationship between any member of the 
Cr?dit Agricole group and the recipient or constitute investment advice. 
The content of this email should not be copied or disclosed (in whole or 
part) to any other person. It may contain information which is 
confidential, privileged or otherwise protected from disclosure. If you 
are not the intended recipient, you should notify us and delete it from 
your system. Emails may be monitored, are not secure and may be amended, 
destroyed or contain viruses and in communicating with us such conditions 
are accepted. Any content which does not relate to business matters is not 
endorsed by us.

Calyon is authorised by the Commission Bancaire in France and regulated by 
the Financial Services Authority for the conduct of business in the 
United Kingdom. Calyon is incorporated in France with limited liability 
and registered in England & Wales. Registration number: FC008194. 
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.


From jim at zope.com  Wed Aug 13 16:54:17 2008
From: jim at zope.com (Jim Fulton)
Date: Wed, 13 Aug 2008 10:54:17 -0400
Subject: [Distutils] [buildout] looking for review of docs on find-links
In-Reply-To: <48A2C446.5080000@simplistix.co.uk>
References: <48A2C446.5080000@simplistix.co.uk>
Message-ID: <728B4047-A06A-4669-AE78-A2C0FAB9DBB9@zope.com>


On Aug 13, 2008, at 7:23 AM, Chris Withers wrote:

> Hi,
>
> I just added some docs for the find-links option:
>
> http://mail.zope.org/pipermail/checkins/2008-August/023822.html

Cool. Thanks.

> I'm not 100% on the order of searching of locations specified in  
> find-links and whether or not pypi is still searched.

For buildout, the index is always searched, because it always wants to  
find the newest.  (This could probably be optimized in certain  
situations.) I'm not sure about the order, but it doesnt' really matter.

> Would be great if someone could have a look and let me know if I  
> need to make any changes.


Looks good to me.

Jim

--
Jim Fulton
Zope Corporation



From pje at telecommunity.com  Wed Aug 13 17:31:04 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 13 Aug 2008 11:31:04 -0400
Subject: [Distutils] Is it possible to stop easy_install from checking
 pypi
In-Reply-To: <94bdd2610808130639r18d3cf17t9cbffb05cd62d95@mail.gmail.com
 >
References: <48A2C446.5080000@simplistix.co.uk>
	<7F347D91614EBC48AA7540A2A76D3BB201EC4992@MXCU10MX1.MSX.CIB>
	<94bdd2610808130639r18d3cf17t9cbffb05cd62d95@mail.gmail.com>
Message-ID: <20080813153013.457503A403D@sparrow.telecommunity.com>

At 03:39 PM 8/13/2008 +0200, Tarek Ziad? wrote:
>On Wed, Aug 13, 2008 at 3:34 PM, Fadhley Salim 
><<mailto:fadhley.salim at uk.calyon.com>fadhley.salim at uk.calyon.com> wrote:
>If the packages cannot be found in the URLs that I specify in find-links
>easy_install always checks pypi.
>
>Is there some way to prevent this? I'd like to ensure that pypi is never
>checked.
>
>
>Hello
>
>You can use the --allow-hosts option to filter out authorized sites
>
>see :
>
><http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-downloads-with-allow-hosts>http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-downloads-with-allow-hosts
>
>Although, I think you might encouter a bug with links starting with file://

The next setuptools release will fix that bug.  But really, there's 
very little reason to use file:// links, anyway.  The only thing they 
do differently from plain paths is that if you use a file:// url to 
point to an HTML file, easy_install will scan it for links.  (It 
doesn't do that for regular filenames.)  So, unless you are using 
HTML files for your local index, there's no need to use file:// urls 
with --find-links.


From ziade.tarek at gmail.com  Wed Aug 13 18:31:51 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 13 Aug 2008 18:31:51 +0200
Subject: [Distutils] Is it possible to stop easy_install from checking
	pypi
In-Reply-To: <20080813153013.457503A403D@sparrow.telecommunity.com>
References: <48A2C446.5080000@simplistix.co.uk>
	<7F347D91614EBC48AA7540A2A76D3BB201EC4992@MXCU10MX1.MSX.CIB>
	<94bdd2610808130639r18d3cf17t9cbffb05cd62d95@mail.gmail.com>
	<20080813153013.457503A403D@sparrow.telecommunity.com>
Message-ID: <94bdd2610808130931t5519c10bldd97c3d16f03b480@mail.gmail.com>

On Wed, Aug 13, 2008 at 5:31 PM, Phillip J. Eby <pje at telecommunity.com>wrote:

> At 03:39 PM 8/13/2008 +0200, Tarek Ziad? wrote:
>
>> On Wed, Aug 13, 2008 at 3:34 PM, Fadhley Salim <<mailto:
>> fadhley.salim at uk.calyon.com>fadhley.salim at uk.calyon.com> wrote:
>> If the packages cannot be found in the URLs that I specify in find-links
>> easy_install always checks pypi.
>>
>> Is there some way to prevent this? I'd like to ensure that pypi is never
>> checked.
>>
>>
>> Hello
>>
>> You can use the --allow-hosts option to filter out authorized sites
>>
>> see :
>>
>> <
>> http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-downloads-with-allow-hosts
>> >
>> http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-downloads-with-allow-hosts
>>
>> Although, I think you might encouter a bug with links starting with
>> file://
>>
>
> The next setuptools release will fix that bug.


Great thanks


> But really, there's very little reason to use file:// links, anyway.  The
> only thing they do differently from plain paths is that if you use a file://
> url to point to an HTML file, easy_install will scan it for links.  (It
> doesn't do that for regular filenames.)  So, unless you are using HTML files
> for your local index, there's no need to use file:// urls with --find-links.
>

Yes that was it, a local html file built by a third party script,

Tarek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080813/4401f06f/attachment.htm>

From jim at zope.com  Wed Aug 13 20:00:13 2008
From: jim at zope.com (Jim Fulton)
Date: Wed, 13 Aug 2008 14:00:13 -0400
Subject: [Distutils] [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <a26746990808131022l4e0946a0qd6ee63031c8f7b4e@mail.gmail.com>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<BA62AA2F-8249-4D11-90FC-680FE2CF8A32@zope.com>
	<a26746990808120141t4f63b622ma24ac8427eb20ca0@mail.gmail.com>
	<148B5531-CBA3-4BB2-AEDB-860EF85E50B3@zope.com>
	<a26746990808120513w34df129ap44c6ea971df1255c@mail.gmail.com>
	<20080812150824.20D4B3A4093@sparrow.telecommunity.com>
	<a26746990808131022l4e0946a0qd6ee63031c8f7b4e@mail.gmail.com>
Message-ID: <FDFE439E-8136-41C2-B5A1-DD9954F00069@zope.com>


Switching to distutils

On Aug 13, 2008, at 1:22 PM, Tarek Ziade wrote:
...
> Besides this feature, there's one feature we started to add on  
> zc.buildout but could be put in setuptools's PackageIndex as well I  
> believe :
>
> Adding timeouts for url openings, to speed up the processing. For  
> instance, when several urls are visited for
> a given package, and when a server pointed by one of the url is  
> down, it can last forever.


Speaking of speed, if someone wants a project, it would be really nice  
someday to make requests in parallel, either using threads or using an  
async-based library like Twisted.

Jim

--
Jim Fulton
Zope Corporation



From chris at simplistix.co.uk  Wed Aug 13 22:13:11 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 13 Aug 2008 21:13:11 +0100
Subject: [Distutils] [buildout] looking for review of docs on find-links
In-Reply-To: <728B4047-A06A-4669-AE78-A2C0FAB9DBB9@zope.com>
References: <48A2C446.5080000@simplistix.co.uk>
	<728B4047-A06A-4669-AE78-A2C0FAB9DBB9@zope.com>
Message-ID: <48A34057.4000502@simplistix.co.uk>

Jim Fulton wrote:
> 
>> I'm not 100% on the order of searching of locations specified in 
>> find-links and whether or not pypi is still searched.
> 
> For buildout, the index is always searched, because it always wants to 
> find the newest.

Okay, so the index is set to PyPI's simple index by default, right?

I'm guessing find-links adds locations to search that are checked before 
the index is specified, correct?

>  (This could probably be optimized in certain 
> situations.) I'm not sure about the order, but it doesnt' really matter.

Indeed. The docs I've written suggest that there is an order and after a 
package has been found searching stops.

On IRC today, Philipp suggested that all options specified in find-links 
were checked for all packages and the latest version found was used.

Jim, can you clarify what exactly the case is here so I can make sure 
the docs aren't misleading people?

cheers,

Chris

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

From asmodai at in-nomine.org  Wed Aug 13 22:31:56 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Wed, 13 Aug 2008 22:31:56 +0200
Subject: [Distutils] Setuptools: build_requires?
Message-ID: <20080813203156.GG87062@nexus.in-nomine.org>

So I am curious, why doesn't setuptools provide a build_requires directive
similar to install_requires, but for python setup.py build?

Right now a particular Python module will fail if you import said
dependency somewhere in your code.

Centralizing such a dependency in setup.py seems, to me, very logical. So
what gives?

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Courage is not the absence of fear, but rather the judgment that
something else is more important than fear.

From pje at telecommunity.com  Wed Aug 13 22:51:38 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 13 Aug 2008 16:51:38 -0400
Subject: [Distutils] Setuptools: build_requires?
In-Reply-To: <20080813203156.GG87062@nexus.in-nomine.org>
References: <20080813203156.GG87062@nexus.in-nomine.org>
Message-ID: <20080813205046.A249D3A403D@sparrow.telecommunity.com>

At 10:31 PM 8/13/2008 +0200, Jeroen Ruigrok van der Werven wrote:
>So I am curious, why doesn't setuptools provide a build_requires 
>directive similar to install_requires, but for python setup.py 
>build? Right now a particular Python module will fail if you import 
>said dependency somewhere in your code. Centralizing such a 
>dependency in setup.py seems, to me, very logical. So what gives? -- 
>Jeroen Ruigrok van der Werven

 From 
http://peak.telecommunity.com/DevCenter/setuptools#new-and-changed-setup-keywords 
:

"""setup_requires

A string or list of strings specifying what other distributions need 
to be present in order for the setup script to run. setuptools will 
attempt to obtain these (even going so far as to download them using 
EasyInstall) before processing the rest of the setup script or 
commands. This argument is needed if you are using distutils 
extensions as part of your build process; for example, extensions 
that process setup() arguments and turn them into EGG-INFO metadata files.

(Note: projects listed in setup_requires will NOT be automatically 
installed on the system where the setup script is being run. They are 
simply downloaded to the setup directory if they're not locally 
available already. If you want them to be installed, as well as being 
available when the setup script is run, you should add them to 
install_requires and setup_requires.)"""

(Note, by the way, that this doesn't allow you to import those 
dependencies at the top level of your setup script; the imports have 
to take place in command classes at the moment.)


From jim at zope.com  Wed Aug 13 23:40:52 2008
From: jim at zope.com (Jim Fulton)
Date: Wed, 13 Aug 2008 17:40:52 -0400
Subject: [Distutils] [buildout] looking for review of docs on find-links
In-Reply-To: <48A34057.4000502@simplistix.co.uk>
References: <48A2C446.5080000@simplistix.co.uk>
	<728B4047-A06A-4669-AE78-A2C0FAB9DBB9@zope.com>
	<48A34057.4000502@simplistix.co.uk>
Message-ID: <799582D1-E0C5-42C6-889F-68EC84CE9838@zope.com>


On Aug 13, 2008, at 4:13 PM, Chris Withers wrote:

> Jim Fulton wrote:
>>> I'm not 100% on the order of searching of locations specified in  
>>> find-links and whether or not pypi is still searched.
>> For buildout, the index is always searched, because it always wants  
>> to find the newest.
>
> Okay, so the index is set to PyPI's simple index by default, right?

Yes

> I'm guessing find-links adds locations to search that are checked  
> before the index is specified, correct?

As I mentioned in my previous message, I don't know the order and I  
don't think it matters. AFAICT, the order isn't specified by  
setuptools and, therefore, might change in the future.

>> (This could probably be optimized in certain situations.) I'm not  
>> sure about the order, but it doesnt' really matter.
>
> Indeed. The docs I've written suggest that there is an order

They should not


> and after a package has been found searching stops.

I missed that. It doesn't.

> On IRC today, Philipp suggested that all options specified in find- 
> links were checked for all packages and the latest version found was  
> used.

The latest version that satisfies the requirement.  In fact, nothing  
is searched if the latest version satisfying the requirement is  
already installed.

Jim

--
Jim Fulton
Zope Corporation



From cdcasey at gmail.com  Wed Aug 13 23:57:55 2008
From: cdcasey at gmail.com (chris)
Date: Wed, 13 Aug 2008 16:57:55 -0500
Subject: [Distutils] install --no-deps
Message-ID: <ead057790808131457v5259359atc215b708c296b20@mail.gmail.com>

There doesn't seem to be a --no-deps option for install the way there
is for develop. Is there a way to perform a python setup.py install
and not have it rely on looking for dependencies?

-Chris

From pje at telecommunity.com  Thu Aug 14 01:06:09 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 13 Aug 2008 19:06:09 -0400
Subject: [Distutils] install --no-deps
In-Reply-To: <ead057790808131457v5259359atc215b708c296b20@mail.gmail.com
 >
References: <ead057790808131457v5259359atc215b708c296b20@mail.gmail.com>
Message-ID: <20080813230517.D643E3A403D@sparrow.telecommunity.com>

At 04:57 PM 8/13/2008 -0500, chris wrote:
>There doesn't seem to be a --no-deps option for install the way there
>is for develop. Is there a way to perform a python setup.py install
>and not have it rely on looking for dependencies?

Use "setup.py easy_install [options] ."  (The "." means, install 
using the setup script in the current directory.)


From gour at mail.inet.hr  Thu Aug 14 09:58:19 2008
From: gour at mail.inet.hr (Gour)
Date: Thu, 14 Aug 2008 09:58:19 +0200
Subject: [Distutils] relocation R_X86_64_32 against `a local symbol' can not
	be used...
Message-ID: <87prockoys.fsf@nitai.hr>

Hi!

I am trying to install pyswisseph
(http://pypi.python.org/pypi/pyswisseph) extension on my x86_64 system,
but building of extension fails with:

[gour at nitai pyswisseph-1.74.00-0] python setup.py --verbose build 
rm -f *.o swetest libswe*
gcc	 -c -g -O9 -Wall -pedantic 	   swedate.c     
In file included from swephexp.h:80,
                 from swedate.c:86:
sweodef.h:201: warning: ISO C90 does not support ?long long?
gcc	 -c -g -O9 -Wall -pedantic 	   swehouse.c     
In file included from swehouse.c:62:
sweodef.h:201: warning: ISO C90 does not support ?long long?
gcc	 -c -g -O9 -Wall -pedantic 	   swejpl.c     
In file included from swephexp.h:80,
                 from swejpl.c:71:
sweodef.h:201: warning: ISO C90 does not support ?long long?
gcc	 -c -g -O9 -Wall -pedantic 	   swemmoon.c     
In file included from swephexp.h:80,
                 from swemmoon.c:182:
sweodef.h:201: warning: ISO C90 does not support ?long long?
gcc	 -c -g -O9 -Wall -pedantic 	   swemplan.c     
In file included from swephexp.h:80,
                 from swemplan.c:63:
sweodef.h:201: warning: ISO C90 does not support ?long long?
gcc	 -c -g -O9 -Wall -pedantic 	   swepcalc.c     
In file included from swephexp.h:80,
                 from swepcalc.h:75,
                 from swepcalc.c:76:
sweodef.h:201: warning: ISO C90 does not support ?long long?
swepcalc.c: In function ?calcserv?:
swepcalc.c:169: warning: ?rspeed? may be used uninitialized in this function
swepcalc.c: In function ?nacalc?:
swepcalc.c:134: warning: ?rspeed? may be used uninitialized in this function
gcc	 -c -g -O9 -Wall -pedantic 	   sweph.c     
In file included from swejpl.h:68,
                 from sweph.c:66:
sweodef.h:201: warning: ISO C90 does not support ?long long?
sweph.c: In function ?app_pos_etc_plan?:
sweph.c:2143: warning: array subscript is above array bounds
gcc	 -c -g -O9 -Wall -pedantic 	   swepdate.c     
In file included from swephexp.h:80,
                 from swepcalc.h:75,
                 from swepdate.c:77:
sweodef.h:201: warning: ISO C90 does not support ?long long?
gcc	 -c -g -O9 -Wall -pedantic 	   swephlib.c     
In file included from swephexp.h:80,
                 from swephlib.c:79:
sweodef.h:201: warning: ISO C90 does not support ?long long?
gcc	 -c -g -O9 -Wall -pedantic 	   swecl.c     
In file included from swejpl.h:68,
                 from swecl.c:62:
sweodef.h:201: warning: ISO C90 does not support ?long long?
swecl.c: In function ?swe_lun_occult_when_glob?:
swecl.c:1093: warning: ?tjd? may be used uninitialized in this function
ar r libswe.a	swedate.o swehouse.o swejpl.o swemmoon.o swemplan.o
swepcalc.o \
sweph.o swepdate.o swephlib.o swecl.o 
ar: creating libswe.a
running build
running build_ext
building 'swisseph' extension
skipping pyswisseph.c (build/temp.linux-x86_64-2.5/pyswisseph.o up-to-date)
skipping swhdatetime.c (build/temp.linux-x86_64-2.5/swhdatetime.o up-to-date)
skipping swhfmt.c (build/temp.linux-x86_64-2.5/swhfmt.o up-to-date)
skipping swhsearch.c (build/temp.linux-x86_64-2.5/swhsearch.o up-to-date)
gcc -pthread -shared build/temp.linux-x86_64-2.5/pyswisseph.o \
build/temp.linux-x86_64-2.5/swhdatetime.o
build/temp.linux-x86_64-2.5/swhfmt.o \
build/temp.linux-x86_64-2.5/swhsearch.o -Lsrc -L/usr/lib -lswe
-lpython2.5 \
-o build/lib.linux-x86_64-2.5/swisseph.so
/usr/bin/ld: src/libswe.a(swedate.o): relocation R_X86_64_32 against `a
local symbol' can not be used when making a shared object; recompile
with -fPIC

src/libswe.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1


Here is the setup.py:

[gour at nitai pyswisseph-1.74.00-0] cat  setup.py 
#!/usr/bin/env python
# -*- coding: utf8 -*-

import os.path, sys
From distutils.core import setup, Extension

VERSION = '1.74.00-0'

if 'build' in sys.argv or 'install' in sys.argv:
	instdir = os.path.dirname(os.path.abspath(__file__))
	os.chdir(os.path.join(instdir, 'src'))
	os.system('make clean')
	os.system('make libswe.a')
	os.chdir(instdir)

swemodule = Extension(
	'swisseph',
	include_dirs = ['src'],
	libraries = ['swe'],
	library_dirs = ['src'],
	sources = ['pyswisseph.c', 'swhdatetime.c', 'swhfmt.c', 'swhsearch.c']
)

setup(
	name = 'pyswisseph',
	version = VERSION,
	description='Python extension to the Swiss Ephemeris',
	long_description="""Python extension to AstroDienst's Swiss Ephemeris library.

Swiss Ephemeris homepage: http://www.astro.com/swisseph

Now Python 3 compatible (experimental).

Usage example:

>>> import swisseph as swe
>>> swe.set_ephe_path('/usr/share/ephe') # set path to ephemeris files
>>> now = swe.julday(2007,3,3) # get Julian day number
>>> res = swe.lun_eclipse_when(now) # find next lunar eclipse (from now on)
>>> ecltime = swe.revjul(res[1][0]) # get date UTC
>>> ecltime
(2007, 3, 3, 23.347975596785545)
>>> jd = swe.julday(2008,3,21)
>>> swe.calc_ut(jd, swe.AST_OFFSET+13681)[0] # asteroid Monty Python
0.098474291148756998
>>> help(swe)

Installation via: # python setup.py install

""",
	author='S.Marquis',
	author_email='stnsls at gmail.com',
	url='http://pyswisseph.atarax.org',
	download_url='http://pypi.python.org/pypi/pyswisseph',
	classifiers=[
		'Development Status :: 5 - Production/Stable',
		'Intended Audience :: Developers',
		'Intended Audience :: Religion',
		'License :: OSI Approved :: GNU General Public License (GPL)',
		'Programming Language :: C',
		'Programming Language :: Python',
		'Topic :: Religion',
		'Topic :: Scientific/Engineering :: Astronomy',
		'Topic :: Software Development :: Libraries :: Python Modules'
		],
	keywords='Astrology Ephemeris Swisseph',
	ext_modules = [swemodule]
)

# End.


I'm quite new (just started learning Python) with Python and its tools,
but, afaik, "recompile with -fPIC" means that something is missing so
that extension is not compiled properly.

I use:

[gour at nitai pyswisseph-1.74.00-0] gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared \
--enable-languages=c,c++,fortran,objc,obj-c++,treelang \
--enable-threads=posix --mandir=/usr/share/man --enable-__cxa_atexit \
--disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib \
--enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic
Thread model: posix
gcc version 4.3.1 20080724 (prerelease) (GCC)

on:

[gour at nitai pyswisseph-1.74.00-0] uname -a
Linux nitai 2.6.25-ARCH #1 SMP PREEMPT Mon Jul 14 14:56:27 UTC 2008 \
x86_64 AMD Turion(tm) 64 Mobile ML-34 AuthenticAMD GNU/Linux


Any idea?


Sincerely,
Gour

-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080814/6d025583/attachment.pgp>

From chris at simplistix.co.uk  Thu Aug 14 12:13:01 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 14 Aug 2008 11:13:01 +0100
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
In-Reply-To: <CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com>
References: <48A2A7F2.8040402@simplistix.co.uk>
	<CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com>
Message-ID: <48A4052D.6060608@simplistix.co.uk>

Jim Fulton wrote:
> 
>> However, given that the demo egg is a binary egg, I can't decide what 
>> the best way to do this is.
> 
> We could just show the contents of setup.py or simply explain, perhaps 
> in a footnote that the scripts are defined via entry points, giving a 
> link to the setuptools documentation.

To be honest, given the use of the demo egg all over the place, maybe 
it'd be better just to have it as a static directory in the distribution?
Is there any technical reason that means we can't do this?

>> I'd thought of using the zipfile module to reach inside the egg, but 
>> I'm confused as to why -py2.3.egg files are specified in the test and 
>> work even though I'm running with python 2.4 and there's no python 2.3 
>> in sight?
> 
> The examples have to show something, The tests have to be run with 
> multiple versions of Python, since multiple versions of Python are 
> supported.  An output normalizer takes care adjusting actual and 
> expected output for the version of Python used at run time.

Okay, so if I wanted to use ZipFile to reach inside an egg, what path 
should I use to open? Is the normalisation code available as a function 
anywhere?

cheers,

Chris

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

From gour at mail.inet.hr  Thu Aug 14 12:25:50 2008
From: gour at mail.inet.hr (Gour)
Date: Thu, 14 Aug 2008 12:25:50 +0200
Subject: [Distutils] relocation R_X86_64_32 against `a local symbol' can
	not be used...
References: <87prockoys.fsf@nitai.hr>
Message-ID: <87hc9nlwpd.fsf@nitai.hr>

>>>>> "Gour" == Gour  <gour at mail.inet.hr> writes:

Excuse me for the noise.

Gour> I'm quite new (just started learning Python) with Python and its
Gour> tools, but, afaik, "recompile with -fPIC" means that something is
Gour> missing so that extension is not compiled properly.

I forgot that pyswisseph package builds libswe.a via Makefile and I
modified it to use autoconf which properly handles -fPIC which I added
in Makefile and now everything is OK.


Sincerely,
Gour

-- 

Gour  | Zagreb, Croatia  | GPG key: C6E7162D
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080814/abb00bc7/attachment.pgp>

From chris at simplistix.co.uk  Thu Aug 14 12:40:28 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 14 Aug 2008 11:40:28 +0100
Subject: [Distutils] [buildout] looking for review of docs on find-links
In-Reply-To: <799582D1-E0C5-42C6-889F-68EC84CE9838@zope.com>
References: <48A2C446.5080000@simplistix.co.uk>
	<728B4047-A06A-4669-AE78-A2C0FAB9DBB9@zope.com>
	<48A34057.4000502@simplistix.co.uk>
	<799582D1-E0C5-42C6-889F-68EC84CE9838@zope.com>
Message-ID: <48A40B9C.30702@simplistix.co.uk>

Jim Fulton wrote:
> 
>> Indeed. The docs I've written suggest that there is an order
> 
> They should not
> 
>> and after a package has been found searching stops.
> 
> I missed that. It doesn't.
> 
>> On IRC today, Philipp suggested that all options specified in 
>> find-links were checked for all packages and the latest version found 
>> was used.
> 
> The latest version that satisfies the requirement.  In fact, nothing is 
> searched if the latest version satisfying the requirement is already 
> installed.

Okay, I've updated the docs to reflect this:

http://svn.zope.org/zc.buildout/trunk/src/zc/buildout/buildout.txt?rev=89829&view=auto

Please let me know if any more changes are necessary.

cheers,

Chris

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

From philipp at weitershausen.de  Thu Aug 14 13:14:34 2008
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu, 14 Aug 2008 13:14:34 +0200
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
In-Reply-To: <48A4052D.6060608@simplistix.co.uk>
References: <48A2A7F2.8040402@simplistix.co.uk>	<CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com>
	<48A4052D.6060608@simplistix.co.uk>
Message-ID: <48A4139A.7000806@weitershausen.de>

Chris Withers wrote:
> Jim Fulton wrote:
>>
>>> However, given that the demo egg is a binary egg, I can't decide what 
>>> the best way to do this is.
>>
>> We could just show the contents of setup.py or simply explain, perhaps 
>> in a footnote that the scripts are defined via entry points, giving a 
>> link to the setuptools documentation.
> 
> To be honest, given the use of the demo egg all over the place, maybe 
> it'd be better just to have it as a static directory in the distribution?
> Is there any technical reason that means we can't do this?
> 
>>> I'd thought of using the zipfile module to reach inside the egg, but 
>>> I'm confused as to why -py2.3.egg files are specified in the test and 
>>> work even though I'm running with python 2.4 and there's no python 
>>> 2.3 in sight?
>>
>> The examples have to show something, The tests have to be run with 
>> multiple versions of Python, since multiple versions of Python are 
>> supported.  An output normalizer takes care adjusting actual and 
>> expected output for the version of Python used at run time.
> 
> Okay, so if I wanted to use ZipFile to reach inside an egg, what path 
> should I use to open? Is the normalisation code available as a function 
> anywhere?

pkg_resources (part of setuptools, documented on the setuptools 
homepage) abstract the access to data inside packages, no matter whether 
they're in a zipped egg or not.

From chris at simplistix.co.uk  Thu Aug 14 13:24:12 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 14 Aug 2008 12:24:12 +0100
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
In-Reply-To: <48A4139A.7000806@weitershausen.de>
References: <48A2A7F2.8040402@simplistix.co.uk>	<CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com>
	<48A4052D.6060608@simplistix.co.uk>
	<48A4139A.7000806@weitershausen.de>
Message-ID: <48A415DC.6020609@simplistix.co.uk>

Philipp von Weitershausen wrote:
> pkg_resources (part of setuptools, documented on the setuptools 
> homepage) abstract the access to data inside packages, no matter whether 
> they're in a zipped egg or not.

Yeah, but it's the actual contents of setup.py that I want to show given 
that this is supposed to be documentation ;-)

cheers,

Chris

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

From philipp at weitershausen.de  Thu Aug 14 13:27:40 2008
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu, 14 Aug 2008 13:27:40 +0200
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
In-Reply-To: <48A415DC.6020609@simplistix.co.uk>
References: <48A2A7F2.8040402@simplistix.co.uk>	<CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com>
	<48A4052D.6060608@simplistix.co.uk>
	<48A4139A.7000806@weitershausen.de>
	<48A415DC.6020609@simplistix.co.uk>
Message-ID: <E8168F82-0731-4E7D-9855-E26916925AEC@weitershausen.de>

El 14 Aug 2008, a las 13:24 , Chris Withers escribi?:
> Philipp von Weitershausen wrote:
>> pkg_resources (part of setuptools, documented on the setuptools  
>> homepage) abstract the access to data inside packages, no matter  
>> whether they're in a zipped egg or not.
>
> Yeah, but it's the actual contents of setup.py that I want to show  
> given that this is supposed to be documentation ;-)

setup.py is never part of an .egg file or directory.


From chris at simplistix.co.uk  Thu Aug 14 13:32:23 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 14 Aug 2008 12:32:23 +0100
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
In-Reply-To: <E8168F82-0731-4E7D-9855-E26916925AEC@weitershausen.de>
References: <48A2A7F2.8040402@simplistix.co.uk>	<CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com>
	<48A4052D.6060608@simplistix.co.uk>
	<48A4139A.7000806@weitershausen.de>
	<48A415DC.6020609@simplistix.co.uk>
	<E8168F82-0731-4E7D-9855-E26916925AEC@weitershausen.de>
Message-ID: <48A417C7.2050706@simplistix.co.uk>

Philipp von Weitershausen wrote:
> El 14 Aug 2008, a las 13:24 , Chris Withers escribi?:
>> Philipp von Weitershausen wrote:
>>> pkg_resources (part of setuptools, documented on the setuptools 
>>> homepage) abstract the access to data inside packages, no matter 
>>> whether they're in a zipped egg or not.
>>
>> Yeah, but it's the actual contents of setup.py that I want to show 
>> given that this is supposed to be documentation ;-)
> 
> setup.py is never part of an .egg file or directory.

um? then what *is* it part of? ;-)

Regardless of what it is or isn't, it's the contents of the demo egg's 
setup.py that's currently obfuscated but which would help understanding 
of the docs a lot.

cheers,

Chris

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

From fadhley.salim at uk.calyon.com  Thu Aug 14 14:03:21 2008
From: fadhley.salim at uk.calyon.com (Fadhley Salim)
Date: Thu, 14 Aug 2008 13:03:21 +0100
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
References: <48A2A7F2.8040402@simplistix.co.uk>	<CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com><48A4052D.6060608@simplistix.co.uk><48A4139A.7000806@weitershausen.de><48A415DC.6020609@simplistix.co.uk><E8168F82-0731-4E7D-9855-E26916925AEC@weitershausen.de>
	<48A417C7.2050706@simplistix.co.uk>
Message-ID: <7F347D91614EBC48AA7540A2A76D3BB201EC499B@MXCU10MX1.MSX.CIB>

Surely the easiest way to get that would be direct from SVN? 

The setup.py file would be part of your project. It's used to build the egg but never actually incorporated into the egg - I cannot think what use it would be even if you found a way to break this convention.  

By the way - kudos to you for sorting out the documentation. It's really awesome that somebody is tackling this.

:-)

-----Original Message-----
From: distutils-sig-bounces at python.org [mailto:distutils-sig-bounces at python.org] On Behalf Of Chris Withers
Sent: 14 August 2008 12:32
To: Philipp von Weitershausen
Cc: distutils-sig at python.org
Subject: Re: [Distutils] [buildout] improving zc.recipe.egg's README.txt

Philipp von Weitershausen wrote:
> El 14 Aug 2008, a las 13:24 , Chris Withers escribi?:
>> Philipp von Weitershausen wrote:
>>> pkg_resources (part of setuptools, documented on the setuptools
>>> homepage) abstract the access to data inside packages, no matter 
>>> whether they're in a zipped egg or not.
>>
>> Yeah, but it's the actual contents of setup.py that I want to show 
>> given that this is supposed to be documentation ;-)
> 
> setup.py is never part of an .egg file or directory.

um? then what *is* it part of? ;-)

Regardless of what it is or isn't, it's the contents of the demo egg's setup.py that's currently obfuscated but which would help understanding of the docs a lot.

cheers,

Chris

--
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk _______________________________________________
Distutils-SIG maillist  -  Distutils-SIG at python.org http://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
This email does not create a legal relationship between any member of the 
Cr?dit Agricole group and the recipient or constitute investment advice. 
The content of this email should not be copied or disclosed (in whole or 
part) to any other person. It may contain information which is 
confidential, privileged or otherwise protected from disclosure. If you 
are not the intended recipient, you should notify us and delete it from 
your system. Emails may be monitored, are not secure and may be amended, 
destroyed or contain viruses and in communicating with us such conditions 
are accepted. Any content which does not relate to business matters is not 
endorsed by us.

Calyon is authorised by the Commission Bancaire in France and regulated by 
the Financial Services Authority for the conduct of business in the 
United Kingdom. Calyon is incorporated in France with limited liability 
and registered in England & Wales. Registration number: FC008194. 
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.


From chris at simplistix.co.uk  Thu Aug 14 14:35:08 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 14 Aug 2008 13:35:08 +0100
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
In-Reply-To: <7F347D91614EBC48AA7540A2A76D3BB201EC499B@MXCU10MX1.MSX.CIB>
References: <48A2A7F2.8040402@simplistix.co.uk>	<CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com><48A4052D.6060608@simplistix.co.uk><48A4139A.7000806@weitershausen.de><48A415DC.6020609@simplistix.co.uk><E8168F82-0731-4E7D-9855-E26916925AEC@weitershausen.de>
	<48A417C7.2050706@simplistix.co.uk>
	<7F347D91614EBC48AA7540A2A76D3BB201EC499B@MXCU10MX1.MSX.CIB>
Message-ID: <48A4267C.8030604@simplistix.co.uk>

Fadhley Salim wrote:
> Surely the easiest way to get that would be direct from SVN? 
> 
> The setup.py file would be part of your project. It's used to build the egg but never actually incorporated into the egg - I cannot think what use it would be even if you found a way to break this convention.  

Er? Suggest reading the whole thread. This setup.py is generated as part 
of the doctest setup which obfuscates it significantly.

Chris

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

From tseaver at palladion.com  Thu Aug 14 16:49:50 2008
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 14 Aug 2008 10:49:50 -0400
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
In-Reply-To: <48A417C7.2050706@simplistix.co.uk>
References: <48A2A7F2.8040402@simplistix.co.uk>	<CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com>	<48A4052D.6060608@simplistix.co.uk>	<48A4139A.7000806@weitershausen.de>	<48A415DC.6020609@simplistix.co.uk>	<E8168F82-0731-4E7D-9855-E26916925AEC@weitershausen.de>
	<48A417C7.2050706@simplistix.co.uk>
Message-ID: <48A4460E.2050000@palladion.com>

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

Chris Withers wrote:
> Philipp von Weitershausen wrote:
>> El 14 Aug 2008, a las 13:24 , Chris Withers escribi?:
>>> Philipp von Weitershausen wrote:
>>>> pkg_resources (part of setuptools, documented on the setuptools 
>>>> homepage) abstract the access to data inside packages, no matter 
>>>> whether they're in a zipped egg or not.
>>> Yeah, but it's the actual contents of setup.py that I want to show 
>>> given that this is supposed to be documentation ;-)
>> setup.py is never part of an .egg file or directory.
> 
> um? then what *is* it part of? ;-)

The source distribution (the .tar.gz file made by running 'setup.py sdist').

Eggs are binary distributions (made by running 'setup.py bdist_egg').
They don't contain all the files in the corresponding 'sdist', and
'setup.py' in particular.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIpEYO+gerLs4ltQ4RAlVPAKC15tTDKOs5iJ6/wSCa3LBLOdJRvQCfbRyJ
NHBwO+JIWbuoc5uQjrMi59c=
=JPte
-----END PGP SIGNATURE-----


From philipp at weitershausen.de  Thu Aug 14 17:01:40 2008
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Thu, 14 Aug 2008 17:01:40 +0200
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
In-Reply-To: <48A4460E.2050000@palladion.com>
References: <48A2A7F2.8040402@simplistix.co.uk>	<CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com>	<48A4052D.6060608@simplistix.co.uk>	<48A4139A.7000806@weitershausen.de>	<48A415DC.6020609@simplistix.co.uk>	<E8168F82-0731-4E7D-9855-E26916925AEC@weitershausen.de>
	<48A417C7.2050706@simplistix.co.uk>
	<48A4460E.2050000@palladion.com>
Message-ID: <93CCBE49-3067-4472-A330-F3332FFDA650@weitershausen.de>

El 14 Aug 2008, a las 16:49 , Tres Seaver escribi?:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Chris Withers wrote:
>> Philipp von Weitershausen wrote:
>>> El 14 Aug 2008, a las 13:24 , Chris Withers escribi?:
>>>> Philipp von Weitershausen wrote:
>>>>> pkg_resources (part of setuptools, documented on the setuptools
>>>>> homepage) abstract the access to data inside packages, no matter
>>>>> whether they're in a zipped egg or not.
>>>> Yeah, but it's the actual contents of setup.py that I want to show
>>>> given that this is supposed to be documentation ;-)
>>> setup.py is never part of an .egg file or directory.
>>
>> um? then what *is* it part of? ;-)
>
> The source distribution (the .tar.gz file made by running 'setup.py  
> sdist').
>
> Eggs are binary distributions (made by running 'setup.py bdist_egg').

As Phillip Eby confirmed several times, .egg files are meant to be an  
installation format, not a distribution format (cf. [1]). Note that I  
distinguish .egg files from Eggs-the-concept (development eggs are  
eggs even though they don't come in .egg files, and I consider source  
distributions eggs as well if they have a setup.py and use setuptools).

[1] http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/#comment-34


From tseaver at palladion.com  Thu Aug 14 16:49:50 2008
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 14 Aug 2008 10:49:50 -0400
Subject: [Distutils] [buildout] improving zc.recipe.egg's README.txt
In-Reply-To: <48A417C7.2050706@simplistix.co.uk>
References: <48A2A7F2.8040402@simplistix.co.uk>	<CB52540F-A959-4EEE-94D7-F384D7C6FCE8@zope.com>	<48A4052D.6060608@simplistix.co.uk>	<48A4139A.7000806@weitershausen.de>	<48A415DC.6020609@simplistix.co.uk>	<E8168F82-0731-4E7D-9855-E26916925AEC@weitershausen.de>
	<48A417C7.2050706@simplistix.co.uk>
Message-ID: <48A4460E.2050000@palladion.com>

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

Chris Withers wrote:
> Philipp von Weitershausen wrote:
>> El 14 Aug 2008, a las 13:24 , Chris Withers escribi?:
>>> Philipp von Weitershausen wrote:
>>>> pkg_resources (part of setuptools, documented on the setuptools 
>>>> homepage) abstract the access to data inside packages, no matter 
>>>> whether they're in a zipped egg or not.
>>> Yeah, but it's the actual contents of setup.py that I want to show 
>>> given that this is supposed to be documentation ;-)
>> setup.py is never part of an .egg file or directory.
> 
> um? then what *is* it part of? ;-)

The source distribution (the .tar.gz file made by running 'setup.py sdist').

Eggs are binary distributions (made by running 'setup.py bdist_egg').
They don't contain all the files in the corresponding 'sdist', and
'setup.py' in particular.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIpEYO+gerLs4ltQ4RAlVPAKC15tTDKOs5iJ6/wSCa3LBLOdJRvQCfbRyJ
NHBwO+JIWbuoc5uQjrMi59c=
=JPte
-----END PGP SIGNATURE-----

From cdcasey at gmail.com  Thu Aug 14 18:45:15 2008
From: cdcasey at gmail.com (chris)
Date: Thu, 14 Aug 2008 11:45:15 -0500
Subject: [Distutils] --single-version-externally-managed bug?
Message-ID: <ead057790808140945m18b77d66kff5e6288e5426a22@mail.gmail.com>

I recently installed a package using python setup.py
--single-version-externally-managed --record record.txt option. In my
site-packaged folder, there is now two new folders and a file.

<top-of-package-namespace>/
<package>-<version>.egg-info/
<package>-<version>-nspkg.pth

Now when I start up python, I get the message

'import site' failed; use -v for traceback

When I do python -v, I get the following traceback:

# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /usr/lib/python2.5/site.pyc matches /usr/lib/python2.5/site.py
import site # precompiled from /usr/lib/python2.5/site.pyc
# /usr/lib/python2.5/os.pyc matches /usr/lib/python2.5/os.py
import os # precompiled from /usr/lib/python2.5/os.pyc
import posix # builtin
# /usr/lib/python2.5/posixpath.pyc matches /usr/lib/python2.5/posixpath.py
import posixpath # precompiled from /usr/lib/python2.5/posixpath.pyc
# /usr/lib/python2.5/stat.pyc matches /usr/lib/python2.5/stat.py
import stat # precompiled from /usr/lib/python2.5/stat.pyc
# /usr/lib/python2.5/UserDict.pyc matches /usr/lib/python2.5/UserDict.py
import UserDict # precompiled from /usr/lib/python2.5/UserDict.pyc
# /usr/lib/python2.5/copy_reg.pyc matches /usr/lib/python2.5/copy_reg.py
import copy_reg # precompiled from /usr/lib/python2.5/copy_reg.pyc
# /usr/lib/python2.5/types.pyc matches /usr/lib/python2.5/types.py
import types # precompiled from /usr/lib/python2.5/types.pyc
import _types # builtin
# zipimport: found 78 names in
/usr/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg
# /usr/lib/python2.5/new.pyc matches /usr/lib/python2.5/new.py
import new # precompiled from /usr/lib/python2.5/new.pyc
'import site' failed; traceback:
Traceback (most recent call last):
  File "/usr/lib/python2.5/site.py", line 415, in <module>
    main()
  File "/usr/lib/python2.5/site.py", line 400, in main
    paths_in_sys = addsitepackages(paths_in_sys)
  File "/usr/lib/python2.5/site.py", line 206, in addsitepackages
    addsitedir(sitedir, known_paths)
  File "/usr/lib/python2.5/site.py", line 169, in addsitedir
    addpackage(sitedir, name, known_paths)
  File "/usr/lib/python2.5/site.py", line 138, in addpackage
    exec line
  File "<string>", line 1, in <module>
KeyError: 'enthought'
# /usr/lib/python2.5/warnings.pyc matches /usr/lib/python2.5/warnings.py
import warnings # precompiled from /usr/lib/python2.5/warnings.pyc
# /usr/lib/python2.5/linecache.pyc matches /usr/lib/python2.5/linecache.py
import linecache # precompiled from /usr/lib/python2.5/linecache.pyc
import encodings # directory /usr/lib/python2.5/encodings
# /usr/lib/python2.5/encodings/__init__.pyc matches
/usr/lib/python2.5/encodings/__init__.py
import encodings # precompiled from /usr/lib/python2.5/encodings/__init__.pyc
# /usr/lib/python2.5/codecs.pyc matches /usr/lib/python2.5/codecs.py
import codecs # precompiled from /usr/lib/python2.5/codecs.pyc
import _codecs # builtin
# /usr/lib/python2.5/encodings/aliases.pyc matches
/usr/lib/python2.5/encodings/aliases.py
import encodings.aliases # precompiled from
/usr/lib/python2.5/encodings/aliases.pyc
# /usr/lib/python2.5/encodings/ascii.pyc matches
/usr/lib/python2.5/encodings/ascii.py
import encodings.ascii # precompiled from /usr/lib/python2.5/encodings/ascii.pyc
Python 2.5.1 (r251:54863, Jan 10 2008, 18:01:57)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
dlopen("/usr/lib/python2.5/lib-dynload/readline.so", 2);
import readline # dynamically loaded from
/usr/lib/python2.5/lib-dynload/readline.so
# /usr/lib/python2.5/atexit.pyc matches /usr/lib/python2.5/atexit.py
import atexit # precompiled from /usr/lib/python2.5/atexit.pyc
# /usr/lib/python2.5/rlcompleter.pyc matches /usr/lib/python2.5/rlcompleter.py
import rlcompleter # precompiled from /usr/lib/python2.5/rlcompleter.pyc

From pje at telecommunity.com  Thu Aug 14 22:12:16 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 14 Aug 2008 16:12:16 -0400
Subject: [Distutils] --single-version-externally-managed bug?
In-Reply-To: <ead057790808140945m18b77d66kff5e6288e5426a22@mail.gmail.co
 m>
References: <ead057790808140945m18b77d66kff5e6288e5426a22@mail.gmail.com>
Message-ID: <20080814201125.29E893A403D@sparrow.telecommunity.com>

At 11:45 AM 8/14/2008 -0500, chris wrote:
>I recently installed a package using python setup.py
>--single-version-externally-managed --record record.txt option. In my
>site-packaged folder, there is now two new folders and a file.
>
><top-of-package-namespace>/
><package>-<version>.egg-info/
><package>-<version>-nspkg.pth

What is the contents of the nspkg.pth file?


From setuptools at bugs.python.org  Fri Aug 15 17:41:15 2008
From: setuptools at bugs.python.org (Zooko O'Whielacronx)
Date: Fri, 15 Aug 2008 15:41:15 +0000
Subject: [Distutils] [issue33] zipped eggs cause various problems -- perhaps
	set default setting to unzipped?
In-Reply-To: <1218814875.39.0.443761860339.issue33@psf.upfronthosting.co.za>
Message-ID: <1218814875.39.0.443761860339.issue33@psf.upfronthosting.co.za>


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

per http://mail.python.org/pipermail/python-dev/2008-April/078505.html

installing an egg (with easy_install or ./setup.py install) in zipped form
results in stack traces without source code lines attached. I hereby propose
that zip_safe=False should be the default, unless the package producer and/or
the package consumer specifically indicates that they prefer to zip the egg.

I might be persuaded to change my mind about this if I saw some performance
measurements which showed that zip_safe=False had a high cost. I'm skeptical
that it has a high cost, since I've used it extensively for months (habitually
specifying zip_safe=False in my setup.py files) and I haven't noticed any
performance problem. 

PJE wrote, on the python-dev thread:

"Are you using Python 2.5?  As of 2.5, the linecache module should correctly
read the source line from the present location of the source file the module was
loaded from, regardless of the file name specified in the traceback."

Yes, this was with Python 2.5.1. Note that the module was loaded from a .pyc
file inside a zipped .egg (in the failing case), or from a .pyc file in an
unzipped .egg (in the succeeding case). In the succeeding case, the name of the
.py file, which is encoded inside the .pyc file, had been rewritten during the
install process. 

 Changed 4 months ago by zooko  ?

Here is another case that I encountered yesterday in which eggs being zipped
caused a problem: we're using py2exe to build a Windows executable. (Also we are
using py2app to build a Mac app.)

py2exe can't find Python modules inside zipped eggs, although it can of course
find them in unzipped eggs if the egg is added to the PYTHONPATH. At one point
my programming partner Rob Kinninmont was using a script named ["hatch-eggs.py"
http://allmydata.org/trac/tahoe/browser/misc/hatch-eggs.py?rev=1879]. That
script no longer appears to be needed in our build system, but at this moment I
can't figure out how we give py2exe access to the modules from the eggs that we
installed... It is possible that we've customized the build machine by setting a
distutils config file to say "always_unzip=True". I hope not, because that would
mean our build will fail in mysterious ways when run on a different machine. 

 Changed 4 months ago by zooko  ?

Oh, there it is: our [setup.cfg
http://allmydata.org/trac/tahoe/browser/setup.cfg?rev=1938]. This means our
Windows build will work on other machines, unless they have one of our
dependencies already installed and that dependency is installed in zipped form.
In that case, we'll get some strange error quite late in the process -- possibly
something like the module not being found at run-time.

So, this is another example of how unzipped eggs Just Work in more contexts
(py2exe) than zipped ones do. 

 Changed 4 months ago by nbecker  ?

zipped eggs also breaks pydoc:

http://permalink.gmane.org/gmane.comp.python.devel/93788

Also, not very convenient if you need to view the source or debug. 



Changed 1 month ago by zooko ?

Here's another one:

http://mail.python.org/pipermail/distutils-sig/2008-July/009694.html
Changed 1 month ago by zooko ?

Here's another person who had trouble which he wouldn't have had if eggs were
unzipped by default:

http://mail.python.org/pipermail/distutils-sig/2007-December/008554.html 


Okay, here's the latest entry: my co-worker Greg Hazel, not knowing about the
setup.cfg hack that I described earlier in this ticket, installed one of Tahoe's
dependencies onto a build machine, using the default behavior of easy_install. 
Therefore, later there was a mysterious run-time error in the resulting package
of Tahoe.  Unfortunately I didn't catch this and explain it to Greg right away,
so instead he spent some of his time figuring it out himself.  After
working-around the problem somehow, he reported to his manager: "fixed. you can
say thank you to python eggs for screwing up py2exe's automatic dependency
detection".

(This ticket was imported from my interim setuptools bug tracker:
http://allmydata.org/trac/setuptools/ticket/4
)

----------
messages: 85
nosy: zooko
priority: bug
status: unread
title: zipped eggs cause various problems -- perhaps set default setting to unzipped?

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

From jim at zope.com  Fri Aug 15 17:53:20 2008
From: jim at zope.com (Jim Fulton)
Date: Fri, 15 Aug 2008 11:53:20 -0400
Subject: [Distutils] [issue33] zipped eggs cause various problems --
	perhaps set default setting to unzipped?
In-Reply-To: <1218814875.39.0.443761860339.issue33@psf.upfronthosting.co.za>
References: <1218814875.39.0.443761860339.issue33@psf.upfronthosting.co.za>
Message-ID: <A0B8E8D0-A92A-481B-8866-B310DED8EB8D@zope.com>


On Aug 15, 2008, at 11:41 AM, Zooko O'Whielacronx wrote:
> I might be persuaded to change my mind about this if I saw some  
> performance
> measurements which showed that zip_safe=False had a high cost. I'm  
> skeptical
> that it has a high cost, since I've used it extensively for months  
> (habitually
> specifying zip_safe=False in my setup.py files) and I haven't  
> noticed any
> performance problem.


I have found unzipped eggs to import *faster* yes *faster* than zipped  
eggs.

Jim

--
Jim Fulton
Zope Corporation



From gohanman at gmail.com  Sat Aug 16 04:42:52 2008
From: gohanman at gmail.com (Andy Theuninck)
Date: Fri, 15 Aug 2008 21:42:52 -0500
Subject: [Distutils] bdist_rpm fails - how to change what's included in hard
	linking?
Message-ID: <f8a02f3e0808151942y46faf284y1a0210e1569aebd0@mail.gmail.com>

I'm trying to create an rpm package using bdist_rpm and it's failing.
I can see exactly why it's failing, but I can't coax google into
telling me how to fix it. First I see python create a tarball to put
in the rpm's SOURCES:

creating python-sybase-0.39
making hard links in python-sybase-0.39...
hard linking Sybase.py -> python-sybase-0.39
hard linking blk.c -> python-sybase-0.39
hard linking cmd.c -> python-sybase-0.39
hard linking conn.c -> python-sybase-0.39
hard linking ctx.c -> python-sybase-0.39
hard linking databuf.c -> python-sybase-0.39
hard linking datafmt.c -> python-sybase-0.39
hard linking date.c -> python-sybase-0.39
hard linking datetime.c -> python-sybase-0.39
hard linking iodesc.c -> python-sybase-0.39
hard linking locale.c -> python-sybase-0.39
hard linking money.c -> python-sybase-0.39
hard linking msgs.c -> python-sybase-0.39
hard linking numeric.c -> python-sybase-0.39
hard linking setup.py -> python-sybase-0.39
hard linking sybasect.c -> python-sybase-0.39
tar -cf dist/python-sybase-0.39.tar python-sybase-0.39
gzip -f9 dist/python-sybase-0.39.tar
removing 'python-sybase-0.39' (and everything under it)
copying dist/python-sybase-0.39.tar.gz -> build/bdist.linux-i686/rpm/SOURCES

One of the files required by setup.py (ez_setup.py) isn't getting hard
linked. Thus, when rpmbuild unpacks the above tarball into the rpm
BUILD directory and runs setup.py, it crashes with an ImportError.

How do I adjust what files get hard linked into that tarball?

From chris at simplistix.co.uk  Sun Aug 17 00:40:22 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 16 Aug 2008 23:40:22 +0100
Subject: [Distutils] [buildout] looking for review of docs on find-links
In-Reply-To: <7F347D91614EBC48AA7540A2A76D3BB201EC4993@MXCU10MX1.MSX.CIB>
References: <48A2C446.5080000@simplistix.co.uk>
	<7F347D91614EBC48AA7540A2A76D3BB201EC4993@MXCU10MX1.MSX.CIB>
Message-ID: <48A75756.3020403@simplistix.co.uk>

Fadhley Salim wrote:
> It could describe the consequence of having --find-links on the command
> line, plus find_links= in the distutils.cfg file. From what I can tell,
> you should use one or the other but not both.

Not sure this is the case, I would have thought it would just be the 
same as specifying either more than once, ie: you just get get more than 
one source of links.

cheers,

Chris

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

From dcorson at facebook.com  Tue Aug 19 05:56:10 2008
From: dcorson at facebook.com (dan corson)
Date: Mon, 18 Aug 2008 20:56:10 -0700
Subject: [Distutils] the svn >= 1.5 bug with setuptools/command/sdist.py:
	global name	'log' is not defined
Message-ID: <20080819035610.GA3012@facebook.com>

This was brought up a while back by someone working with experimental 
svn 1.6:
http://mail.python.org/pipermail/distutils-sig/2008-February/008794.html
But I'm not sure it was addressed, and now we're getting the same
problem here with svn 1.5.1.

This same fix fixes it:
--- sdist.py.vanilla    2008-08-18 20:54:07.000000000 -0700
+++ sdist.py    2008-08-18 20:12:11.000000000 -0700
@@ -1,5 +1,6 @@
 from distutils.command.sdist import sdist as _sdist
 from distutils.util import convert_path
+from distutils import log
 import os, re, sys, pkg_resources
 
 entities = [

But I'm not sure it's the best one.  It's definitely good that this fix
should address the problem once and for all (i.e. no re-break on future
svn versions), but maybe there is a better larger fix.  I think it
should be addressed somehow though since svn 1.5.1 is now the latest
release.  Thanks, --dan

From asmodai at in-nomine.org  Tue Aug 19 07:29:19 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Tue, 19 Aug 2008 07:29:19 +0200
Subject: [Distutils] the svn >= 1.5 bug
	with	setuptools/command/sdist.py: global name 'log' is not defined
In-Reply-To: <20080819035610.GA3012@facebook.com>
References: <20080819035610.GA3012@facebook.com>
Message-ID: <20080819052919.GG87062@nexus.in-nomine.org>

-On [20080819 06:19], dan corson (dcorson at facebook.com) wrote:
>But I'm not sure it was addressed, and now we're getting the same
>problem here with svn 1.5.1.

easy_install -U setuptools==dev

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
I disagree with everything you say. But I will defend to the death your
right to say it.

From chris at simplistix.co.uk  Tue Aug 19 11:12:55 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 19 Aug 2008 10:12:55 +0100
Subject: [Distutils] [setuptools] svn'ed file being missed with
	include_package_data=True
Message-ID: <48AA8E97.9060105@simplistix.co.uk>

Hi All,

I have a setup.py that looks roughly like:

import os
from setuptools import setup, find_packages
...
setup(
     ...
     packages=find_packages(),
     zip_safe=False,
     include_package_data=True,
     ...
     )

...and a file layout roughly like:

/bootstrap.py
/buildout.cfg
/setup.py
/mypackage/...

When I do setup.py sdist, the resulting .zip [1] file contains 
bootstrap.py and setup.py but not buildout.cfg, even though it is in svn.

What's going wrong here?

cheers,

Chris

[1] Anyone know how to get .tgz source builds on windows rather than
     .zips?

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

From sdouche at gmail.com  Tue Aug 19 14:44:58 2008
From: sdouche at gmail.com (Sebastien Douche)
Date: Tue, 19 Aug 2008 14:44:58 +0200
Subject: [Distutils] the svn >= 1.5 bug with
	setuptools/command/sdist.py: global name 'log' is not defined
In-Reply-To: <20080819052919.GG87062@nexus.in-nomine.org>
References: <20080819035610.GA3012@facebook.com>
	<20080819052919.GG87062@nexus.in-nomine.org>
Message-ID: <5e1183fa0808190544l67e82675ib993b558cca40642@mail.gmail.com>

On Tue, Aug 19, 2008 at 07:29, Jeroen Ruigrok van der Werven
<asmodai at in-nomine.org> wrote:
> -On [20080819 06:19], dan corson (dcorson at facebook.com) wrote:
>>But I'm not sure it was addressed, and now we're getting the same
>>problem here with svn 1.5.1.
>
> easy_install -U setuptools==dev

I would like to know why 0.7 (or 0.6c9) is not out. This solution is
not clean, and doesn't work with Buildout.
Are there any unrelsolved bugs  ?

-- 
Seb

From ziade.tarek at gmail.com  Tue Aug 19 15:09:36 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 19 Aug 2008 15:09:36 +0200
Subject: [Distutils] the svn >= 1.5 bug with
	setuptools/command/sdist.py: global name 'log' is not defined
In-Reply-To: <5e1183fa0808190544l67e82675ib993b558cca40642@mail.gmail.com>
References: <20080819035610.GA3012@facebook.com>
	<20080819052919.GG87062@nexus.in-nomine.org>
	<5e1183fa0808190544l67e82675ib993b558cca40642@mail.gmail.com>
Message-ID: <94bdd2610808190609j302ca465j50a5ed846baffffd@mail.gmail.com>

On Tue, Aug 19, 2008 at 2:44 PM, Sebastien Douche <sdouche at gmail.com> wrote:

> On Tue, Aug 19, 2008 at 07:29, Jeroen Ruigrok van der Werven
> <asmodai at in-nomine.org> wrote:
> > -On [20080819 06:19], dan corson (dcorson at facebook.com) wrote:
> >>But I'm not sure it was addressed, and now we're getting the same
> >>problem here with svn 1.5.1.
> >
> > easy_install -U setuptools==dev
>
> I would like to know why 0.7 (or 0.6c9) is not out. This solution is
> not clean, and doesn't work with Buildout.


It should work with:

[buildout]
..
versions = versions

[versions]
setuptools = dev

*But* it doesn't because of a bug I mentioned a few months ago:

In setuptools's package_index module, the _download_url determines a
filename using the last part of the URL:

'http://svn.python.org/projects/sandbox/trunk/setuptools/#egg=setuptools-dev
'

becomes

'setuptools'

and it goes to your download folder at:

'..downloads/dist/setuptools'

But this is also the name used by zc.buildout to decompress the package :)

leading to an error, in the next attempt do get setuptools:

IOError: [Errno 21] Is a directory: '.../downloads/dist/setuptools'

In any case, this setuptools behaviour is bad, because if your url is:

'http://svn.example.org/your/package/trunk'

It will end up in a "trunk" folder. And if you have two packages that points
to an url finishing with "trunk"
it will fail.

So, setuptools should use a random, unique, temporary name in this function
imho
to make buildout happy with any kind of dev package.



> Are there any unrelsolved bugs  ?


setuptools has its own tracker here : http://bugs.python.org/setuptools




>
>
> --
> Seb
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080819/5de47902/attachment.htm>

From pje at telecommunity.com  Tue Aug 19 15:41:09 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 19 Aug 2008 09:41:09 -0400
Subject: [Distutils] the svn >= 1.5 bug with
 setuptools/command/sdist.py: global name 'log' is not defined
In-Reply-To: <94bdd2610808190609j302ca465j50a5ed846baffffd@mail.gmail.co
 m>
References: <20080819035610.GA3012@facebook.com>
	<20080819052919.GG87062@nexus.in-nomine.org>
	<5e1183fa0808190544l67e82675ib993b558cca40642@mail.gmail.com>
	<94bdd2610808190609j302ca465j50a5ed846baffffd@mail.gmail.com>
Message-ID: <20080819134019.6DCAD3A4105@sparrow.telecommunity.com>

At 03:09 PM 8/19/2008 +0200, Tarek Ziad? wrote:
>So, setuptools should use a random, unique, temporary name in this 
>function imho
>to make buildout happy with any kind of dev package.

Um, no.  easy_install does *each* download to a unique temporary 
directory.  If buildout is doing something else, it's buildout that's broken.


From ziade.tarek at gmail.com  Tue Aug 19 17:17:24 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 19 Aug 2008 17:17:24 +0200
Subject: [Distutils] the svn >= 1.5 bug with
	setuptools/command/sdist.py: global name 'log' is not defined
In-Reply-To: <20080819134019.6DCAD3A4105@sparrow.telecommunity.com>
References: <20080819035610.GA3012@facebook.com>
	<20080819052919.GG87062@nexus.in-nomine.org>
	<5e1183fa0808190544l67e82675ib993b558cca40642@mail.gmail.com>
	<94bdd2610808190609j302ca465j50a5ed846baffffd@mail.gmail.com>
	<20080819134019.6DCAD3A4105@sparrow.telecommunity.com>
Message-ID: <94bdd2610808190817m43142453y1cab040dd97bb385@mail.gmail.com>

On Tue, Aug 19, 2008 at 3:41 PM, Phillip J. Eby <pje at telecommunity.com>wrote:

> At 03:09 PM 8/19/2008 +0200, Tarek Ziad? wrote:
>
>> So, setuptools should use a random, unique, temporary name in this
>> function imho
>> to make buildout happy with any kind of dev package.
>>
>
> Um, no.  easy_install does *each* download to a unique temporary directory.
>  If buildout is doing something else, it's buildout that's broken.
>
>
Oups right, I thought easy_install worked with the same temp folder in the
same run but it is zc.buildout,

I just found the place where it is not behaving correctly, it does a

>>> index.download('
http://svn.python.org/projects/sandbox/trunk/setuptools/#egg=setuptools-dev',
FOLDER)

where FOLDER may have a "setuptools" directory already

===

Jim do you still dislike the idea of making zc.buildout compatible with
packages downloaded with egg fragments ?

Because even if no one uses such urls in the find-links option, it will be
forced if you try to use "setuptools==dev" in the buildout,
which would be simpler that to use a 'develop' option in that case.

I think the solution is to check for this in Installer._fetch(self, dist,
tmp, download_cache) in zc.buildout/easy_install.py
and do a special treatement when such urls are provided.

Tarek

-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080819/2bc80425/attachment.htm>

From sdouche at gmail.com  Tue Aug 19 17:38:00 2008
From: sdouche at gmail.com (Sebastien Douche)
Date: Tue, 19 Aug 2008 17:38:00 +0200
Subject: [Distutils] the svn >= 1.5 bug with
	setuptools/command/sdist.py: global name 'log' is not defined
In-Reply-To: <20080819134019.6DCAD3A4105@sparrow.telecommunity.com>
References: <20080819035610.GA3012@facebook.com>
	<20080819052919.GG87062@nexus.in-nomine.org>
	<5e1183fa0808190544l67e82675ib993b558cca40642@mail.gmail.com>
	<94bdd2610808190609j302ca465j50a5ed846baffffd@mail.gmail.com>
	<20080819134019.6DCAD3A4105@sparrow.telecommunity.com>
Message-ID: <5e1183fa0808190838l58a44a4btcac7cd0e8a178cc2@mail.gmail.com>

On Tue, Aug 19, 2008 at 15:41, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 03:09 PM 8/19/2008 +0200, Tarek Ziad? wrote:
>>
>> So, setuptools should use a random, unique, temporary name in this
>> function imho
>> to make buildout happy with any kind of dev package.
>
> Um, no.  easy_install does *each* download to a unique temporary directory.
>  If buildout is doing something else, it's buildout that's broken.

I'm talking about the critical bug of Setuptools with SVN 1.5 ( commit
r65222).  So I ask again, why setuptools 0.9c9 is not released ?


-- 
Seb

From Citrix at ifc14.com  Tue Aug 19 18:05:20 2008
From: Citrix at ifc14.com (Citrix GoToAssist Corporate)
Date: Tue, 19 Aug 2008 12:05:20 -0400
Subject: [Distutils] Forrester Research: Best Practices for the Service Desk
Message-ID: <20080819165546.874CC1E4009@bag.python.org>


ZoomInfo Business and Industry Information 
-------------------------------------------------------------

Download the Complimentary Research Report

According to a study conducted by Forrester Research,
only 53 percent of surveyed IT users reported being
satisfied with their help desk support. Areas such
as resolving users? requests in a timely manner and
successfully resolving an issue on the first call
were identified as key opportunities for improvement.

Download the Forrester research report, ?Thirty-One Best
Practices for the Service Desk,? to discover proven
industry best practices, processes and technologies.

Click below to download the Report:
http://www.ifc14.com/ets/clk.asp?69040X1M9461355

-- Quickly resolve technical problems and save time 
-- Rapidly resolve complex, mission-critical incidents 
-- Handle increasing call volume without increasing budgets 

Click below to download the Forrester best-practices
research report:
http://www.ifc14.com/ets/clk.asp?69040X1M9461355

For more information please call (800) 549-8541.  If you
are calling from outside the United States, please call:
+1 (805) 690-5729.

=================================================================

Citrix Online | 5385 Hollister Avenue | Santa Barbara, CA 93111
Voice: 800.549.8541 | Fax: 805.690.6471
(C)2008 Citrix Online, LLC. All Rights Reserved.

To unsubscribe from future Citrix Online mailings, please visit:
http://www.citrixonline.com/unsubscribe.tmpl

-------------------------------------------------------------
[ distutils-sig at python.org ]
The preceding is an email advertisement.

To remove yourself from future promotions, please click here:
http://www.ifc14.com/r/rm.asp?m=PngfCYY&o=gPKnK&j=fCgZK&t=2&e=distutils-sig at python.org
or copy and paste the above link into your internet browser.
9461355


-------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080819/fe9be692/attachment-0001.htm>

From chris at simplistix.co.uk  Tue Aug 19 19:13:31 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 19 Aug 2008 18:13:31 +0100
Subject: [Distutils] [setuptools] svn'ed file being missed with
	include_package_data=True
In-Reply-To: <ead057790808191011i1e5c507fuc11f13f2c9017899@mail.gmail.com>
References: <48AA8E97.9060105@simplistix.co.uk>
	<ead057790808191011i1e5c507fuc11f13f2c9017899@mail.gmail.com>
Message-ID: <48AAFF3B.70101@simplistix.co.uk>

chris wrote:
> What version of subversion are you using? 

1.4.5

cheers,

Chris

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

From v.dijk.bas at gmail.com  Wed Aug 20 10:16:52 2008
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Wed, 20 Aug 2008 10:16:52 +0200
Subject: [Distutils] Missing import in setuptools/commands/sdist.py
Message-ID: <f73f66150808200116k431c4875yc5deea09324ff8c8@mail.gmail.com>

Hello,

"from distutils import log" should be added to:
"setuptools/command/sdist.py" because on line 99 there's a "log.warn(...)"

regards

Bas

From ziade.tarek at gmail.com  Wed Aug 20 10:31:52 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 20 Aug 2008 10:31:52 +0200
Subject: [Distutils] Missing import in setuptools/commands/sdist.py
In-Reply-To: <f73f66150808200116k431c4875yc5deea09324ff8c8@mail.gmail.com>
References: <f73f66150808200116k431c4875yc5deea09324ff8c8@mail.gmail.com>
Message-ID: <94bdd2610808200131s7a013c65gc711621c7ec06cd4@mail.gmail.com>

On Wed, Aug 20, 2008 at 10:16 AM, Bas van Dijk <v.dijk.bas at gmail.com> wrote:

> Hello,
>
> "from distutils import log" should be added to:
> "setuptools/command/sdist.py" because on line 99 there's a "log.warn(...)"
>

It was corrected in the trunk

http://svn.python.org/projects/sandbox/trunk/setuptools/setuptools/command/sdist.py

but I don't know when the next release will be out.

Until then you can use the trunk version by installing setuptools-dev :

$ easy_install -U setuptools==dev

For other feedback you can use the bug tracker here :
http://bugs.python.org/setuptools/

Regards

Tarek




>
> regards
>
> Bas
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080820/84599e17/attachment.htm>

From setuptools at bugs.python.org  Wed Aug 20 10:32:45 2008
From: setuptools at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 20 Aug 2008 08:32:45 +0000
Subject: [Distutils] [issue34] add a link to the bug tracker in README.txt
In-Reply-To: <1219221165.76.0.122334497893.issue34@psf.upfronthosting.co.za>
Message-ID: <1219221165.76.0.122334497893.issue34@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

It would be nice to add http://bugs.python.org/setuptools/ in the README.txt so
it appears in the PyPI page

----------
messages: 88
nosy: tarek
priority: wish
status: unread
title: add a link to the bug tracker in README.txt

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

From v.dijk.bas at gmail.com  Wed Aug 20 10:52:11 2008
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Wed, 20 Aug 2008 10:52:11 +0200
Subject: [Distutils] Missing import in setuptools/commands/sdist.py
In-Reply-To: <94bdd2610808200131s7a013c65gc711621c7ec06cd4@mail.gmail.com>
References: <f73f66150808200116k431c4875yc5deea09324ff8c8@mail.gmail.com>
	<94bdd2610808200131s7a013c65gc711621c7ec06cd4@mail.gmail.com>
Message-ID: <f73f66150808200152o53ba8d31r9793ab922ea5e2ce@mail.gmail.com>

On Wed, Aug 20, 2008 at 10:31 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> It was corrected in the trunk

Nice

Bas

From novalis at openplans.org  Wed Aug 20 22:40:12 2008
From: novalis at openplans.org (David Turner)
Date: Wed, 20 Aug 2008 16:40:12 -0400
Subject: [Distutils] Setuptools download cache
Message-ID: <1219264812.12685.46.camel@gentle>

Attached is a patch which adds download caching to setuptools.

At TOPP (http://topp.openplans.org/), we use a system called fassembler
to build our opencore stack.  It creates approximately a dozen
virtualenvs, each with their own lib/python, and then uses setuptools to
install lots of libraries.  Some of these libraries are common among
multiple apps, but we install multiple copies for ease of development.
And every time we rebuild, we start the whole process over again.  The
major slowdown in building is downloading a bunch of things which
probably haven't changed since last time we downloaded them.   This
patch will let us maintain a cache of all downloads, and thus do builds
much faster.

Anyway, I hope you'll accept this patch.  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cache-dir.patch
Type: text/x-patch
Size: 5760 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080820/67783b67/attachment.bin>

From pje at telecommunity.com  Thu Aug 21 00:39:23 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 20 Aug 2008 18:39:23 -0400
Subject: [Distutils] Setuptools download cache
In-Reply-To: <1219264812.12685.46.camel@gentle>
References: <1219264812.12685.46.camel@gentle>
Message-ID: <20080820223831.310943A4079@sparrow.telecommunity.com>

At 04:40 PM 8/20/2008 -0400, David Turner wrote:
>Attached is a patch which adds download caching to setuptools.
>
>At TOPP (http://topp.openplans.org/), we use a system called fassembler
>to build our opencore stack.  It creates approximately a dozen
>virtualenvs, each with their own lib/python, and then uses setuptools to
>install lots of libraries.  Some of these libraries are common among
>multiple apps, but we install multiple copies for ease of development.
>And every time we rebuild, we start the whole process over again.  The
>major slowdown in building is downloading a bunch of things which
>probably haven't changed since last time we downloaded them.   This
>patch will let us maintain a cache of all downloads, and thus do builds
>much faster.

The process I'd suggest for this use case is to build the external 
libraries using:

    easy_install -f cache_dir -zmaxd cache_dir lib1 lib2 ...

This command will NOT go to the web for new versions of libraries, 
unless you also use -U.  But it will ensure that the specified 
libraries have suitable eggs in cache_dir.

Then, to install a given set of libraries to a virtualenv, use:

    easy_install -f cache_dir lib1 lib2 ...

Or, if you really insist on multiple copies of the eggs (instead of 
just linking to them), use:

    easy_install -af cache_dir lib1 lib2 ...

(which will copy the .egg files even if they could be used in place).

Unlike your caching proposal, this approach gives you finer control 
over which libraries to update, when.  You can also update the cache 
without changing what's installed in a given virtualenv.


From tarek.ziade at ingeniweb.com  Thu Aug 21 14:59:58 2008
From: tarek.ziade at ingeniweb.com (Tarek Ziade)
Date: Thu, 21 Aug 2008 14:59:58 +0200
Subject: [Distutils] [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <20080820134254.7C0493A4079@sparrow.telecommunity.com>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<BA62AA2F-8249-4D11-90FC-680FE2CF8A32@zope.com>
	<a26746990808120141t4f63b622ma24ac8427eb20ca0@mail.gmail.com>
	<148B5531-CBA3-4BB2-AEDB-860EF85E50B3@zope.com>
	<a26746990808120513w34df129ap44c6ea971df1255c@mail.gmail.com>
	<20080812150824.20D4B3A4093@sparrow.telecommunity.com>
	<a26746990808131022l4e0946a0qd6ee63031c8f7b4e@mail.gmail.com>
	<20080820134254.7C0493A4079@sparrow.telecommunity.com>
Message-ID: <a26746990808210559s6a17998h36bfd7e7e027fb1b@mail.gmail.com>

2008/8/20 Phillip J. Eby <pje at telecommunity.com>

> At 07:22 PM 8/13/2008 +0200, Tarek Ziade wrote:
>
>> 2008/8/12 Phillip J. Eby <<mailto:pje at telecommunity.com>
>> pje at telecommunity.com>
>> What you really want/need is to make the PackageIndex support retrieval
>> from multiple index urls; the PackageIndex itself aggregates available
>> packages from sources such as the local file system, -f urls, and an
>> underlying package index.  So having multiple aggregators would duplicate
>> processing, and deprive you of a global ordering of package precedences.
>>
>> Is this a feature you would like to see in setuptools ? If so I can write
>> a patch,
>>
>
> Just be aware that I'm likely to be rather picky about how it works.  :)


I bet, I'll give a try and submit it :)


>
>
>
>  Besides this feature, there's one feature we started to add on zc.buildout
>> but could be put in setuptools's PackageIndex as well I believe :
>>
>
> Having the option to set a short timeout for *connections* would be useful,
> I think, just as long as it doesn't end up cutting off slow downloads.  I'd
> prefer it to be controllable from the command line, nonetheless.
>
>
As far as I know, the socket timeout will not apply on a download that is
beeing processed, but only on 'sleeping' connections.
For instance, if I download Firefox with urlopen(), it takes up to 1 second
to read() it and the timeout won't occur in that case :

>>> import socket
>>> socket.setdefaulttimeout(1)
>>> import urllib2
>>> g = urllib2.urlopen('
http://www.gtlib.gatech.edu/pub/mozilla.org/firefox/releases/3.0.1/mac/fr/Firefox%203.0.1.dmg
')
>>> g.read()
xxxxxxx I get firefox dmg file here

Although I don't know how it behaves on stale connections, I will digg on
this

Tarek


-- 
Tarek Ziad? - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080821/53a61770/attachment.htm>

From chris at simplistix.co.uk  Thu Aug 21 18:45:21 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 21 Aug 2008 17:45:21 +0100
Subject: [Distutils] [setuptools] include_package_data=True missing
 files even when specified in MANIFEST.in
In-Reply-To: <48AA8E97.9060105@simplistix.co.uk>
References: <48AA8E97.9060105@simplistix.co.uk>
Message-ID: <48AD9BA1.8070804@simplistix.co.uk>

Chris Withers wrote:
> Hi All,
> 
> I have a setup.py that looks roughly like:
> 
> import os
> from setuptools import setup, find_packages
> ...
> setup(
>     ...
>     packages=find_packages(),
>     zip_safe=False,
>     include_package_data=True,
>     ...
>     )
> 
> ...and a file layout roughly like:
> 
> /bootstrap.py
> /buildout.cfg
> /setup.py
> /mypackage/...
> 
> When I do setup.py sdist, the resulting .zip [1] file contains 
> bootstrap.py and setup.py but not buildout.cfg, even though it is in svn.

I tried to brute force this by adding a MANIFEST.in next to setup.py 
containing :

recursive-include . *.cfg

...but still buldout.cfg wasn't included.

*sigh*

Any ideas?

Chris

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

From pje at telecommunity.com  Thu Aug 21 23:56:09 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 21 Aug 2008 17:56:09 -0400
Subject: [Distutils] [PATCH][setuptools] Add test_runner support to setup
In-Reply-To: <1207482058.5957.0.camel@localhost>
References: <1207408509.6012.9.camel@localhost>
	<20080405235300.795DE3A4042@sparrow.telecommunity.com>
	<1207482058.5957.0.camel@localhost>
Message-ID: <20080821215513.1DB573A403D@sparrow.telecommunity.com>

FYI, I've added this feature to the trunk (for 0.7a1), but it will 
not be added to 0.6.  Use "easy_install setuptools==dev" to get the 
trunk version.  Thanks.

At 01:40 PM 4/6/2008 +0200, Klaus Zimmermann wrote:
>Am Samstag, den 05.04.2008, 19:53 -0400 schrieb Phillip J. Eby:
> > At 05:15 PM 4/5/2008 +0200, Klaus Zimmermann wrote:
> > >Hi all,
> > >
> > >for our nightly build system I needed the capability to use a different
> > >test runner, namely one that outputs junit compatible xml files.
> > >In order to support that through the setup.py test command I hacked on
> > >setuptools.
> > >
> > >Is there a simpler way to do this?
> > >If not you might want to consider attached patch for addition
> > >(Should be against latest svn.)
> >
> > Add documentation to the patch and you've got yourself a deal.  :)
>
>Updated patch attached.
>Have fun,
>Klaus


From pje at telecommunity.com  Fri Aug 22 00:01:59 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 21 Aug 2008 18:01:59 -0400
Subject: [Distutils] Your message to Distutils-SIG awaits moderator
	approval
In-Reply-To: <mailman.20975.1219350522.920.distutils-sig@python.org>
References: <mailman.20975.1219350522.920.distutils-sig@python.org>
Message-ID: <20080821220104.1FC523A403D@sparrow.telecommunity.com>

Anybody know what would be considered a suspicious header in this case?  :)

At 10:28 PM 8/21/2008 +0200, distutils-sig-bounces at python.org wrote:
>Your mail to 'Distutils-SIG' with the subject
>
>     Testers wanted: about a dozen setuptools bugs closed in trunk
>
>Is being held until the list moderator can review it for approval.
>
>The reason it is being held:
>
>     Message has a suspicious header
>
>Either the message will get posted to the list, or you will receive
>notification of the moderator's decision.  If you would like to cancel
>this posting, please visit the following URL:
>
> 
>http://mail.python.org/mailman/confirm/distutils-sig/58606f8fcc1f092cd925937d2c4a621132cec285


From ziade.tarek at gmail.com  Fri Aug 22 00:12:16 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 22 Aug 2008 00:12:16 +0200
Subject: [Distutils] [Catalog-sig] High-availability for PyPI,
	mirroring infrastructures?
In-Reply-To: <a26746990808210559s6a17998h36bfd7e7e027fb1b@mail.gmail.com>
References: <69827A17F9EBCBA3995FD60A@192.168.0.24>
	<BA62AA2F-8249-4D11-90FC-680FE2CF8A32@zope.com>
	<a26746990808120141t4f63b622ma24ac8427eb20ca0@mail.gmail.com>
	<148B5531-CBA3-4BB2-AEDB-860EF85E50B3@zope.com>
	<a26746990808120513w34df129ap44c6ea971df1255c@mail.gmail.com>
	<20080812150824.20D4B3A4093@sparrow.telecommunity.com>
	<a26746990808131022l4e0946a0qd6ee63031c8f7b4e@mail.gmail.com>
	<20080820134254.7C0493A4079@sparrow.telecommunity.com>
	<a26746990808210559s6a17998h36bfd7e7e027fb1b@mail.gmail.com>
Message-ID: <94bdd2610808211512l7865409ct688d40642d77f9db@mail.gmail.com>

On Thu, Aug 21, 2008 at 2:59 PM, Tarek Ziade <tarek.ziade at ingeniweb.com>wrote:

>
>
> 2008/8/20 Phillip J. Eby <pje at telecommunity.com>
>
>> At 07:22 PM 8/13/2008 +0200, Tarek Ziade wrote:
>>
>>> 2008/8/12 Phillip J. Eby <<mailto:pje at telecommunity.com>
>>> pje at telecommunity.com>
>>> What you really want/need is to make the PackageIndex support retrieval
>>> from multiple index urls; the PackageIndex itself aggregates available
>>> packages from sources such as the local file system, -f urls, and an
>>> underlying package index.  So having multiple aggregators would duplicate
>>> processing, and deprive you of a global ordering of package precedences.
>>>
>>> Is this a feature you would like to see in setuptools ? If so I can write
>>> a patch,
>>>
>>
>> Just be aware that I'm likely to be rather picky about how it works.  :)
>
>
> I bet, I'll give a try and submit it :)
>

Ok I have submitted a patch here http://bugs.python.org/setuptools/issue32

I have added a test where I played with two indexes: Pypi and another custom
one, that hold a package version
PyPI don't.

I changed the code accordingly,  and recorded all urllib2.urlopen
input/output into a mapping saved in a shelve file,
so the test can work without external calls. (maybe this could be pushed in
a  helper in the sandbox)

I have also added a deprecation warning, but I don't know if this is
something you want..

I have tested it successfully with several buildouts and I will test it more
this week, together with your latest bug fixes.

Tarek

-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080822/db09c240/attachment.htm>

From tarek.ziade at ingeniweb.com  Fri Aug 22 00:31:58 2008
From: tarek.ziade at ingeniweb.com (Tarek Ziade)
Date: Fri, 22 Aug 2008 00:31:58 +0200
Subject: [Distutils] Your message to Distutils-SIG awaits moderator
	approval
In-Reply-To: <20080821220104.1FC523A403D@sparrow.telecommunity.com>
References: <mailman.20975.1219350522.920.distutils-sig@python.org>
	<20080821220104.1FC523A403D@sparrow.telecommunity.com>
Message-ID: <a26746990808211531t75c86f90gb846550b820b0562@mail.gmail.com>

2008/8/22 Phillip J. Eby <pje at telecommunity.com>

> Anybody know what would be considered a suspicious header in this case?  :)
>

I think it is a pattern caught by Mailman's bounce_matching_headers option

So maybe: "subject: .*wanted:.*"


> At 10:28 PM 8/21/2008 +0200, distutils-sig-bounces at python.org wrote:
>
>> Your mail to 'Distutils-SIG' with the subject
>>
>>    Testers wanted: about a dozen setuptools bugs closed in trunk
>>
>> Is being held until the list moderator can review it for approval.
>>
>> The reason it is being held:
>>
>>    Message has a suspicious header
>>
>> Either the message will get posted to the list, or you will receive
>> notification of the moderator's decision.  If you would like to cancel
>> this posting, please visit the following URL:
>>
>>
>>
>> http://mail.python.org/mailman/confirm/distutils-sig/58606f8fcc1f092cd925937d2c4a621132cec285
>>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Tarek Ziad? - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080822/7719ad3b/attachment-0001.htm>

From fadhley.salim at uk.calyon.com  Fri Aug 22 18:33:45 2008
From: fadhley.salim at uk.calyon.com (Fadhley Salim)
Date: Fri, 22 Aug 2008 17:33:45 +0100
Subject: [Distutils] Question about finding downloads (with distutils.cfg)
References: <1207408509.6012.9.camel@localhost><20080405235300.795DE3A4042@sparrow.telecommunity.com><1207482058.5957.0.camel@localhost>
	<20080821215513.1DB573A403D@sparrow.telecommunity.com>
Message-ID: <7F347D91614EBC48AA7540A2A76D3BB201EC49B7@MXCU10MX1.MSX.CIB>

I have a distutils.cfg file which looks something like this:

-----------

[easy_install]

find_links=http://europe1.internal/eggs
           http://europe2.internal/eggs
           http://europe3.internal/eggs
           \\usa1.internal\eggs
           \\usa2.internal\eggs

-----------

All of the five sources contain the exact same collection of files. 

Most users who can access the european web-servers cannot access the
American UNC paths and vice-versa.

That usually works out well, because the sources a user cannot access
will quickly time-out and the user will get the egg they need from a
source they can access.

The problem comes with users who can access both the web-servers *and*
the UNC paths easy_install. For example a mobile, "international" user
might have access to everything but with a slow connection.

Even if the egg needed can be found on any one of the hosts the
remaining two (the UNC paths) will always be checked by setuptools. This
makes setuptools run very slow indeed:

I have found that easy_install is needlessly checking all five sources
even if checking only one would be good enough.

Is there a way to make setuptools stop searching as soon as it's found
the first source which contains the required egg?

Sal

PS. I'm using setuptools-0.6c8-py2.4.egg
-------------- next part --------------
This email does not create a legal relationship between any member of the 
Cr?dit Agricole group and the recipient or constitute investment advice. 
The content of this email should not be copied or disclosed (in whole or 
part) to any other person. It may contain information which is 
confidential, privileged or otherwise protected from disclosure. If you 
are not the intended recipient, you should notify us and delete it from 
your system. Emails may be monitored, are not secure and may be amended, 
destroyed or contain viruses and in communicating with us such conditions 
are accepted. Any content which does not relate to business matters is not 
endorsed by us.

Calyon is authorised by the Commission Bancaire in France and regulated by 
the Financial Services Authority for the conduct of business in the 
United Kingdom. Calyon is incorporated in France with limited liability 
and registered in England & Wales. Registration number: FC008194. 
Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.


From pje at telecommunity.com  Thu Aug 21 22:08:42 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 21 Aug 2008 16:08:42 -0400
Subject: [Distutils] Testers wanted: about a dozen setuptools bugs closed in
	trunk
Message-ID: <20080821200747.70C443A403D@sparrow.telecommunity.com>

I've checked in numerous fixes to bugs from the tracker today, with 
the intention to cut a c9 release on Monday.  Please update with 
"easy_install setuptools==dev", and try it out.  Thanks!


From novalis at openplans.org  Fri Aug 22 21:20:07 2008
From: novalis at openplans.org (David Turner)
Date: Fri, 22 Aug 2008 15:20:07 -0400
Subject: [Distutils] Setuptools download cache
In-Reply-To: <20080820223831.310943A4079@sparrow.telecommunity.com>
References: <1219264812.12685.46.camel@gentle>
	<20080820223831.310943A4079@sparrow.telecommunity.com>
Message-ID: <1219432807.11937.14.camel@gentle>

On Wed, 2008-08-20 at 18:39 -0400, Phillip J. Eby wrote:
> At 04:40 PM 8/20/2008 -0400, David Turner wrote:
> >Attached is a patch which adds download caching to setuptools.
> >
> >At TOPP (http://topp.openplans.org/), we use a system called fassembler
> >to build our opencore stack.  It creates approximately a dozen
> >virtualenvs, each with their own lib/python, and then uses setuptools to
> >install lots of libraries.  Some of these libraries are common among
> >multiple apps, but we install multiple copies for ease of development.
> >And every time we rebuild, we start the whole process over again.  The
> >major slowdown in building is downloading a bunch of things which
> >probably haven't changed since last time we downloaded them.   This
> >patch will let us maintain a cache of all downloads, and thus do builds
> >much faster.
> 
> The process I'd suggest for this use case is to build the external 
> libraries using:
> 
>     easy_install -f cache_dir -zmaxd cache_dir lib1 lib2 ...
> 
> This command will NOT go to the web for new versions of libraries, 
> unless you also use -U.  But it will ensure that the specified 
> libraries have suitable eggs in cache_dir.
> 
> Then, to install a given set of libraries to a virtualenv, use:
> 
>     easy_install -f cache_dir lib1 lib2 ...
> 
> Or, if you really insist on multiple copies of the eggs (instead of 
> just linking to them), use:
> 
>     easy_install -af cache_dir lib1 lib2 ...
> 
> (which will copy the .egg files even if they could be used in place).
> 
> Unlike your caching proposal, this approach gives you finer control 
> over which libraries to update, when.  You can also update the cache 
> without changing what's installed in a given virtualenv.

I'm having a very hard time getting it working, actually.  I should note
that I'm not using easy_install directly, but through setup.py.  This is
because I don't want to have to list all my dependencies twice, and
setup.py passes options on to easy_install, as I understand it.

 Here's a simple test case:

1. Create a virtualenv:

$ virtualenv.py /tmp/testve

2. Activate

$ cd /tmp/testve
$ . bin/activate

3. Check out Cabochon.

(testve)$ svn co https://svn.openplans.org/svn/Cabochon/trunk cabochon

4. Try to set up

(testve)$ mkdir /tmp/ec2 # the cache directory
(testve)$ cd cabochon
(testve)$ python setup.py develop -f /tmp/ec2 -zmaxd /tmp/ec2
running develop
Checking .pth file support in /tmp/ec2
/tmp/testve/bin/python -E -c pass
running egg_info
creating Cabochon.egg-info
writing requirements to Cabochon.egg-info/requires.txt
writing Cabochon.egg-info/PKG-INFO
writing top-level names to Cabochon.egg-info/top_level.txt
writing dependency_links to Cabochon.egg-info/dependency_links.txt
writing entry points to Cabochon.egg-info/entry_points.txt
writing manifest file 'Cabochon.egg-info/SOURCES.txt'
writing manifest file 'Cabochon.egg-info/SOURCES.txt'
running build_ext
Creating /tmp/ec2/Cabochon.egg-link (link to .)

Installed /tmp/testve/cabochon

Because this distribution was installed --multi-version, before you can
import modules from this package in an application, you will need to
'import pkg_resources' and then use a 'require()' call similar to one of
these examples, in order to select the desired version:

    pkg_resources.require("Cabochon")  # latest installed version
    pkg_resources.require("Cabochon==0.2dev-r19871")  # this exact
version
    pkg_resources.require("Cabochon>=0.2dev-r19871")  # this version or
higher


Note also that the installation directory must be on sys.path at runtime
for
this to work.  (e.g. by being the application's script directory, by
being on
PYTHONPATH, or by being added to sys.path by your code.)
[many more lines of this as it installs all the requirements]
5. Try to run

(testve)$ paster
bash: paster: command not found

6. Hm, that's no good.  Well, what if we just manually try to see if
stuff is installed:

(testve)$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cabochon
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "cabochon/__init__.py", line 8, in <module>
    from cabochon.config.middleware import make_app
  File "cabochon/config/middleware.py", line 2, in <module>
    from paste import httpexceptions
ImportError: No module named paste

Nope.


From dpeterson at enthought.com  Sat Aug 23 01:05:37 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Fri, 22 Aug 2008 18:05:37 -0500
Subject: [Distutils] [setuptools] svn'ed file being missed
	with	include_package_data=True
In-Reply-To: <48AA8E97.9060105@simplistix.co.uk>
References: <48AA8E97.9060105@simplistix.co.uk>
Message-ID: <48AF4641.10205@enthought.com>

Chris Withers wrote:
> [1] Anyone know how to get .tgz source builds on windows rather than
>     .zips?

Yes, do 'python setup.py sdist --formats=gztar'.

You can find this yourself by doing 'python setup.py sdist -h' which 
will show (among other things):

Options for 'sdist' command:
  --formats         formats for source distribution (comma-separated list)
  --keep-temp (-k)  keep the distribution tree around after creating archive
                    file(s)
  --dist-dir (-d)   directory to put the source distribution archive(s) in
                    [default: dist]
  --help-formats    list available distribution formats


And then a 'python setup.py sdist --help-formats' results in:

List of available source distribution formats:
  --formats=bztar  bzip2'ed tar-file
  --formats=gztar  gzip'ed tar-file
  --formats=tar    uncompressed tar file
  --formats=zip    ZIP file
  --formats=ztar   compressed tar file


-- Dave


From dpeterson at enthought.com  Sat Aug 23 01:17:04 2008
From: dpeterson at enthought.com (Dave Peterson)
Date: Fri, 22 Aug 2008 18:17:04 -0500
Subject: [Distutils] [tg-trunk] Re: [ANN] EggFreezer
In-Reply-To: <489B1F12.7010305@colorstudy.com>
References: <48983A0E.5090902@toscat.net>	<489872F2.4090305@colorstudy.com>	<489878B0.20304@toscat.net>	<48987AD2.7000205@colorstudy.com>	<48988471.8020703@toscat.net>	<4898A741.3070201@colorstudy.com>	<41799.84.20.17.84.1218112128.squirrel@correo.toscat.com>
	<489B1F12.7010305@colorstudy.com>
Message-ID: <48AF48F0.2060303@enthought.com>

Ian Bicking wrote:
> Alberto Valverde wrote:
>>> Alberto Valverde wrote:
>>> [...]
>>>
>>> Reading a comment on the philikon article
>>> (http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/#comment-47), 
>>>
>>> I also notice that Enthought has done some work on this, it seems by
>>> fixing up the binary packages at install time.  This seems to be 
>>> related
>>> to an entirely different issue of the location of libraries and binary
>>> incompatibilities, which I only slightly understand.
>>
>> Very interesting... some code doing this is not available anywhere 
>> for me
>> to study/steal, right? :)
>
> Probably, but you'd have to ask the Enthought guys.


Sorry for the long delay in responding, the SciPy conference and EPD/ETS 
releases have kept me quite busy and I hadn't read this mailing list in 
weeks. :-(

Enthought established a "post install" pattern in some of our egg's 
EGG_INFO dirs so that we could run a tool derived from easy_install that 
would automatically run scripts when the egg was installed or 
uninstalled.   These scripts then run, among other things, chrpath on 
linux, macholib on OS/X, etc to fix up paths to non-pytho libs given the 
user's install location for the egg.  The trouble here is that the users 
of the egg have to use the derived tool rather than the standard one.   
This is fine if you have a closed system, but difficult if you're trying 
to publish eggs to PyPi, etc. for use by the world.

The tool's source is in our OSS repo here:  
https://svn.enthought.com/svn/enthought/Enstaller/trunk

I'd recommend asking questions on enthought-dev if you have any 
questions about that code.


-- Dave



From pjenvey at underboss.org  Sat Aug 23 10:33:22 2008
From: pjenvey at underboss.org (Philip Jenvey)
Date: Sat, 23 Aug 2008 01:33:22 -0700
Subject: [Distutils] Testers wanted: about a dozen setuptools bugs
	closed in trunk
In-Reply-To: <20080821200747.70C443A403D@sparrow.telecommunity.com>
References: <20080821200747.70C443A403D@sparrow.telecommunity.com>
Message-ID: <A32557D8-94B0-4D56-B148-DF10DF14D142@underboss.org>


On Aug 21, 2008, at 1:08 PM, Phillip J. Eby wrote:

> I've checked in numerous fixes to bugs from the tracker today, with  
> the intention to cut a c9 release on Monday.  Please update with  
> "easy_install setuptools==dev", and try it out.  Thanks!

Could you weigh in on my latest response/plea for: http://bugs.python.org/setuptools/issue27

It's a big deal for Jython and I'd like to get it resolved for this  
release

--
Philip Jenvey



From h.goebel at goebel-consult.de  Sat Aug 23 18:11:10 2008
From: h.goebel at goebel-consult.de (Hartmut Goebel)
Date: Sat, 23 Aug 2008 18:11:10 +0200
Subject: [Distutils] embedding eggs into .msi (or another installer)
Message-ID: <48B0369E.2070506@goebel-consult.de>

Hi,

coming from Unix, I now want to be helpful to Windows-users and prepare 
some installable package for one of my tools 
(http://pdfposter.origo.ehtz.ch).

Since py2exe does not work in Unix and not even on wine, I'm currently 
stuck with bdist_msi or bdist_wininst. This works fine so far. 
Unfortunately pdfposter requires another package (pyPdf) which is 
available as win32-installer.

Now the user of pdfposter would need to download and install both 
packages, one by one.

I'm looking for a solution for packaging pyPdf into the same 
msi/installer as pdfposter and install pyPdf if missing on the target 
system.

Any hints? Any recipes?

-- 
Sch?nen Gru? - Regards
Hartmut Goebel
Dilp.-Informatiker (univ.), CISSP

Goebel Consult
Spezialist f?r IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4719 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080823/b9007642/attachment.bin>

From pje at telecommunity.com  Sun Aug 24 21:32:19 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 24 Aug 2008 15:32:19 -0400
Subject: [Distutils] Question about finding downloads (with
 distutils.cfg)
In-Reply-To: <7F347D91614EBC48AA7540A2A76D3BB201EC49B7@MXCU10MX1.MSX.CIB
 >
References: <1207408509.6012.9.camel@localhost>
	<20080405235300.795DE3A4042@sparrow.telecommunity.com>
	<1207482058.5957.0.camel@localhost>
	<20080821215513.1DB573A403D@sparrow.telecommunity.com>
	<7F347D91614EBC48AA7540A2A76D3BB201EC49B7@MXCU10MX1.MSX.CIB>
Message-ID: <20080824193122.E503A3A403D@sparrow.telecommunity.com>

At 05:33 PM 8/22/2008 +0100, Fadhley Salim wrote:
>All of the five sources contain the exact same collection of files.
>
>Most users who can access the european web-servers cannot access the
>American UNC paths and vice-versa.
>
>That usually works out well, because the sources a user cannot access
>will quickly time-out and the user will get the egg they need from a
>source they can access.
>
>The problem comes with users who can access both the web-servers *and*
>the UNC paths easy_install. For example a mobile, "international" user
>might have access to everything but with a slow connection.
>
>Even if the egg needed can be found on any one of the hosts the
>remaining two (the UNC paths) will always be checked by setuptools. This
>makes setuptools run very slow indeed:
>
>I have found that easy_install is needlessly checking all five sources
>even if checking only one would be good enough.
>
>Is there a way to make setuptools stop searching as soon as it's found
>the first source which contains the required egg?

Yes and no.  The issue here is that easy_install sees the UNC paths 
as local, so it should actually check them *first*, and then skip the 
URLs if the requirements can be met.  However, once easy_install has 
checked even one URL, it will check any subsequent URLs immediately.

So, in theory, you could make it check the UNC paths first and not 
the URLs, but you might find it difficult to lock down in 
practice.  Plus, it doesn't actually fix your problem, if I 
understand it correctly.


From pje at telecommunity.com  Sun Aug 24 21:40:39 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 24 Aug 2008 15:40:39 -0400
Subject: [Distutils] Setuptools download cache
In-Reply-To: <1219432807.11937.14.camel@gentle>
References: <1219264812.12685.46.camel@gentle>
	<20080820223831.310943A4079@sparrow.telecommunity.com>
	<1219432807.11937.14.camel@gentle>
Message-ID: <20080824193944.BBBE43A410E@sparrow.telecommunity.com>

At 03:20 PM 8/22/2008 -0400, David Turner wrote:
>On Wed, 2008-08-20 at 18:39 -0400, Phillip J. Eby wrote:
> > At 04:40 PM 8/20/2008 -0400, David Turner wrote:
> > >Attached is a patch which adds download caching to setuptools.
> > >
> > >At TOPP (http://topp.openplans.org/), we use a system called fassembler
> > >to build our opencore stack.  It creates approximately a dozen
> > >virtualenvs, each with their own lib/python, and then uses setuptools to
> > >install lots of libraries.  Some of these libraries are common among
> > >multiple apps, but we install multiple copies for ease of development.
> > >And every time we rebuild, we start the whole process over again.  The
> > >major slowdown in building is downloading a bunch of things which
> > >probably haven't changed since last time we downloaded them.   This
> > >patch will let us maintain a cache of all downloads, and thus do builds
> > >much faster.
> >
> > The process I'd suggest for this use case is to build the external
> > libraries using:
> >
> >     easy_install -f cache_dir -zmaxd cache_dir lib1 lib2 ...
> >
> > This command will NOT go to the web for new versions of libraries,
> > unless you also use -U.  But it will ensure that the specified
> > libraries have suitable eggs in cache_dir.
> >
> > Then, to install a given set of libraries to a virtualenv, use:
> >
> >     easy_install -f cache_dir lib1 lib2 ...
> >
> > Or, if you really insist on multiple copies of the eggs (instead of
> > just linking to them), use:
> >
> >     easy_install -af cache_dir lib1 lib2 ...
> >
> > (which will copy the .egg files even if they could be used in place).
> >
> > Unlike your caching proposal, this approach gives you finer control
> > over which libraries to update, when.  You can also update the cache
> > without changing what's installed in a given virtualenv.
>
>I'm having a very hard time getting it working, actually.  I should note
>that I'm not using easy_install directly, but through setup.py.  This is
>because I don't want to have to list all my dependencies twice, and
>setup.py passes options on to easy_install, as I understand it.

You don't have to specify dependencies twice.  Just do:

    easy_install -f cache_dir -zmaxd cache_dir path_to_checkout

It will then build an egg from the checkout and copy it and all the 
dependencies to the cache dir.



>  Here's a simple test case:
>
>1. Create a virtualenv:
>
>$ virtualenv.py /tmp/testve
>
>2. Activate
>
>$ cd /tmp/testve
>$ . bin/activate
>
>3. Check out Cabochon.
>
>(testve)$ svn co https://svn.openplans.org/svn/Cabochon/trunk cabochon
>
>4. Try to set up
>
>(testve)$ mkdir /tmp/ec2 # the cache directory

Here, you should run easy_install -f /tmp/ec2 -zmaxd /tmp/ec2 cabochon


>(testve)$ cd cabochon
>(testve)$ python setup.py develop -f /tmp/ec2 -zmaxd /tmp/ec2

Then here, run:

    python setup.py develop -af /tmp/ec2

This will then copy any dependency eggs from the cache dir to the 
virtualenv, and set up the checkout for development.

>running develop
>Checking .pth file support in /tmp/ec2
>/tmp/testve/bin/python -E -c pass
>running egg_info
>creating Cabochon.egg-info
>writing requirements to Cabochon.egg-info/requires.txt
>writing Cabochon.egg-info/PKG-INFO
>writing top-level names to Cabochon.egg-info/top_level.txt
>writing dependency_links to Cabochon.egg-info/dependency_links.txt
>writing entry points to Cabochon.egg-info/entry_points.txt
>writing manifest file 'Cabochon.egg-info/SOURCES.txt'
>writing manifest file 'Cabochon.egg-info/SOURCES.txt'
>running build_ext
>Creating /tmp/ec2/Cabochon.egg-link (link to .)
>
>Installed /tmp/testve/cabochon
>
>Because this distribution was installed --multi-version, before you can
>import modules from this package in an application, you will need to
>'import pkg_resources' and then use a 'require()' call similar to one of
>these examples, in order to select the desired version:
>
>     pkg_resources.require("Cabochon")  # latest installed version
>     pkg_resources.require("Cabochon==0.2dev-r19871")  # this exact
>version
>     pkg_resources.require("Cabochon>=0.2dev-r19871")  # this version or
>higher
>
>
>Note also that the installation directory must be on sys.path at runtime
>for
>this to work.  (e.g. by being the application's script directory, by
>being on
>PYTHONPATH, or by being added to sys.path by your code.)
>[many more lines of this as it installs all the requirements]




>5. Try to run
>
>(testve)$ paster
>bash: paster: command not found
>
>6. Hm, that's no good.  Well, what if we just manually try to see if
>stuff is installed:
>
>(testve)$ python
>Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22)
>[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
>Type "help", "copyright", "credits" or "license" for more information.
> >>> import cabochon
>Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "cabochon/__init__.py", line 8, in <module>
>     from cabochon.config.middleware import make_app
>   File "cabochon/config/middleware.py", line 2, in <module>
>     from paste import httpexceptions
>ImportError: No module named paste
>
>Nope.

This didn't work because you only did half of what I said; you have 
to do the -zmaxd step to load or update the cache, and the -af step 
to actually install your target to the virtualenv.


From setuptools at bugs.python.org  Mon Aug 25 20:00:19 2008
From: setuptools at bugs.python.org (Paul Egan)
Date: Mon, 25 Aug 2008 18:00:19 +0000
Subject: [Distutils] [issue35] mercurial support
In-Reply-To: <1219687219.16.0.365246980531.issue35@psf.upfronthosting.co.za>
Message-ID: <1219687219.16.0.365246980531.issue35@psf.upfronthosting.co.za>


New submission from Paul Egan <paulegan at mail.com>:

Patch to add mercurial support to setuptools:
* Extends setuptools.file_findersAdds with hg repository support
* Adds tag-hg-revision & filter-hgignore-files options to the egg-info command

----------
files: mercurial.diff
messages: 127
nosy: paulegan
priority: feature
status: unread
title: mercurial support
Added file: http://bugs.python.org/setuptools/file16/mercurial.diff

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue35>
_______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mercurial.diff
Type: text/x-patch
Size: 5789 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080825/7c3f8291/attachment.bin>

From pje at telecommunity.com  Mon Aug 25 21:02:20 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 25 Aug 2008 15:02:20 -0400
Subject: [Distutils] Testers wanted: about a dozen setuptools bugs
 closed in trunk
In-Reply-To: <A32557D8-94B0-4D56-B148-DF10DF14D142@underboss.org>
References: <20080821200747.70C443A403D@sparrow.telecommunity.com>
	<A32557D8-94B0-4D56-B148-DF10DF14D142@underboss.org>
Message-ID: <20080825190125.3B8403A403D@sparrow.telecommunity.com>

At 01:33 AM 8/23/2008 -0700, Philip Jenvey wrote:

>On Aug 21, 2008, at 1:08 PM, Phillip J. Eby wrote:
>
>>I've checked in numerous fixes to bugs from the tracker today, with
>>the intention to cut a c9 release on Monday.  Please update with
>>"easy_install setuptools==dev", and try it out.  Thanks!
>
>Could you weigh in on my latest response/plea for: 
>http://bugs.python.org/setuptools/issue27

Yep: provide a (tested) patch that doesn't silently do the wrong 
thing when command-line options are used.


From sdouche at gmail.com  Mon Aug 25 21:14:00 2008
From: sdouche at gmail.com (Sebastien Douche)
Date: Mon, 25 Aug 2008 21:14:00 +0200
Subject: [Distutils] Testers wanted: about a dozen setuptools bugs
	closed in trunk
In-Reply-To: <20080821200747.70C443A403D@sparrow.telecommunity.com>
References: <20080821200747.70C443A403D@sparrow.telecommunity.com>
Message-ID: <5e1183fa0808251214n767b660o7f37e55268f00da9@mail.gmail.com>

On Thu, Aug 21, 2008 at 22:08, Phillip J. Eby <pje at telecommunity.com> wrote:
> I've checked in numerous fixes to bugs from the tracker today, with the
> intention to cut a c9 release on Monday.  Please update with "easy_install
> setuptools==dev", and try it out.  Thanks!

Hi Philip,
tested today without problems (on simple use cases). More tests tomorrow.


-- 
Seb

From novalis at openplans.org  Tue Aug 26 01:06:04 2008
From: novalis at openplans.org (David Turner)
Date: Mon, 25 Aug 2008 19:06:04 -0400
Subject: [Distutils] Setuptools download cache
In-Reply-To: <20080824193944.BBBE43A410E@sparrow.telecommunity.com>
References: <1219264812.12685.46.camel@gentle>
	<20080820223831.310943A4079@sparrow.telecommunity.com>
	<1219432807.11937.14.camel@gentle>
	<20080824193944.BBBE43A410E@sparrow.telecommunity.com>
Message-ID: <1219705564.32138.30.camel@gentle>

I get a really weird error when I try to follow these instructions -- but 
only sometimes.  In order to reproduce the error, you need to start with 
a fresh virtualenv and cache directory (I think).  I can't figure out why.  
And It seems that after I test it a few times with a given piece of
software, the error goes away and I can't reproduce it again.  I'm really 
baffled here.  

Of course, I can just re-run easy_install, and that always clears up the error 
(so far),  but this is not really a good solution.

Processing dependencies for eyvind==0.1dev-r18052
Traceback (most recent call last):
  File "/tmp/test2/bin/easy_install", line 8, in <module>
    load_entry_point('setuptools==0.6c8', 'console_scripts', 'easy_install')()
  File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1671, in main
    with_ei_usage(lambda:
  File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1659, in with_ei_usage
    return f()
  File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 1675, in <lambda>
    distclass=DistributionWithoutHelpCommands, **kw
  File "/usr/lib/python2.5/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 211, in run
    self.easy_install(spec, not self.no_deps)
  File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 427, in easy_install
    return self.install_item(None, spec, tmpdir, deps, True)
  File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 478, in install_item
    self.process_distribution(spec, dist, deps)
  File "/usr/lib/python2.5/site-packages/setuptools/command/easy_install.py", line 519, in process_distribution
    [requirement], self.local_index, self.easy_install
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 529, in resolve
    requirements.extend(dist.requires(req.extras)[::-1])
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 2107, in requires
    dm = self._dep_map
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 2099, in _dep_map
    for extra,reqs in split_sections(self._get_metadata(name)):
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 2518, in split_sections
    for line in yield_lines(s):
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 1813, in yield_lines
    for ss in strs:
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 2121, in _get_metadata
    for line in self.get_metadata_lines(name):
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 1140, in get_metadata_lines
    return yield_lines(self.get_metadata(name))
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 1137, in get_metadata
    return self._get(self._fn(self.egg_info,name))
  File "/usr/lib/python2.5/site-packages/pkg_resources.py", line 1195, in _get
    return self.loader.get_data(path)
zipimport.ZipImportError: bad local file header in /tmp/ec5/eyvind-0.1dev_r18052-py2.5.egg

I have uploaded examples of these eggs to http://novalis.org/bugs/, in case they give any 
hints about what weird thing setuptools is doing. 

Also, I can't easy_install lxml, even though python setup.py develop works fine:

[after checking lxml out from svn]
(test8)novalis at gentle:/tmp/test8$ easy_install -f /tmp/ec9 -zmaxd /tmp/ec9 lxml
Processing lxml
Running setup.py -q bdist_egg --dist-dir /tmp/test8/lxml/egg-dist-tmp-gzDfr3
Building lxml version 2.2.alpha1-57598.
Building with Cython 0.9.8.1.1.
Using build configuration of libxslt 1.1.22
Building against libxml2/libxslt in the following directory: /usr/lib
warning: no files found matching 'lxml.etree.c' under directory 'src/lxml'
warning: no files found matching 'lxml.objectify.c' under directory 'src/lxml'
warning: no files found matching 'lxml.etree.h' under directory 'src/lxml'
warning: no files found matching 'lxml.etree_api.h' under directory 'src/lxml'
warning: no files found matching '*.html' under directory 'doc'
gcc: src/lxml/lxml.etree.c: No such file or directory
gcc: no input files
error: Setup script exited with error: command 'gcc' failed with exit status 1

Any ideas on this one?  I could, I suppose, hard-code that LXML should not be 
easy_installed, but this would be a hack.

On Sun, 2008-08-24 at 15:40 -0400, Phillip J. Eby wrote:
> At 03:20 PM 8/22/2008 -0400, David Turner wrote:
> >On Wed, 2008-08-20 at 18:39 -0400, Phillip J. Eby wrote:
> > > At 04:40 PM 8/20/2008 -0400, David Turner wrote:
> > > >Attached is a patch which adds download caching to setuptools.
> > > >
> > > >At TOPP (http://topp.openplans.org/), we use a system called fassembler
> > > >to build our opencore stack.  It creates approximately a dozen
> > > >virtualenvs, each with their own lib/python, and then uses setuptools to
> > > >install lots of libraries.  Some of these libraries are common among
> > > >multiple apps, but we install multiple copies for ease of development.
> > > >And every time we rebuild, we start the whole process over again.  The
> > > >major slowdown in building is downloading a bunch of things which
> > > >probably haven't changed since last time we downloaded them.   This
> > > >patch will let us maintain a cache of all downloads, and thus do builds
> > > >much faster.
> > >
> > > The process I'd suggest for this use case is to build the external
> > > libraries using:
> > >
> > >     easy_install -f cache_dir -zmaxd cache_dir lib1 lib2 ...
> > >
> > > This command will NOT go to the web for new versions of libraries,
> > > unless you also use -U.  But it will ensure that the specified
> > > libraries have suitable eggs in cache_dir.
> > >
> > > Then, to install a given set of libraries to a virtualenv, use:
> > >
> > >     easy_install -f cache_dir lib1 lib2 ...
> > >
> > > Or, if you really insist on multiple copies of the eggs (instead of
> > > just linking to them), use:
> > >
> > >     easy_install -af cache_dir lib1 lib2 ...
> > >
> > > (which will copy the .egg files even if they could be used in place).
> > >
> > > Unlike your caching proposal, this approach gives you finer control
> > > over which libraries to update, when.  You can also update the cache
> > > without changing what's installed in a given virtualenv.
> >
> >I'm having a very hard time getting it working, actually.  I should note
> >that I'm not using easy_install directly, but through setup.py.  This is
> >because I don't want to have to list all my dependencies twice, and
> >setup.py passes options on to easy_install, as I understand it.
> 
> You don't have to specify dependencies twice.  Just do:
> 
>     easy_install -f cache_dir -zmaxd cache_dir path_to_checkout
> 
> It will then build an egg from the checkout and copy it and all the 
> dependencies to the cache dir.
> 
> 
> 
> >  Here's a simple test case:
> >
> >1. Create a virtualenv:
> >
> >$ virtualenv.py /tmp/testve
> >
> >2. Activate
> >
> >$ cd /tmp/testve
> >$ . bin/activate
> >
> >3. Check out Cabochon.
> >
> >(testve)$ svn co https://svn.openplans.org/svn/Cabochon/trunk cabochon
> >
> >4. Try to set up
> >
> >(testve)$ mkdir /tmp/ec2 # the cache directory
> 
> Here, you should run easy_install -f /tmp/ec2 -zmaxd /tmp/ec2 cabochon
> 
> 
> >(testve)$ cd cabochon
> >(testve)$ python setup.py develop -f /tmp/ec2 -zmaxd /tmp/ec2
> 
> Then here, run:
> 
>     python setup.py develop -af /tmp/ec2
> 
> This will then copy any dependency eggs from the cache dir to the 
> virtualenv, and set up the checkout for development.
> 
> >running develop
> >Checking .pth file support in /tmp/ec2
> >/tmp/testve/bin/python -E -c pass
> >running egg_info
> >creating Cabochon.egg-info
> >writing requirements to Cabochon.egg-info/requires.txt
> >writing Cabochon.egg-info/PKG-INFO
> >writing top-level names to Cabochon.egg-info/top_level.txt
> >writing dependency_links to Cabochon.egg-info/dependency_links.txt
> >writing entry points to Cabochon.egg-info/entry_points.txt
> >writing manifest file 'Cabochon.egg-info/SOURCES.txt'
> >writing manifest file 'Cabochon.egg-info/SOURCES.txt'
> >running build_ext
> >Creating /tmp/ec2/Cabochon.egg-link (link to .)
> >
> >Installed /tmp/testve/cabochon
> >
> >Because this distribution was installed --multi-version, before you can
> >import modules from this package in an application, you will need to
> >'import pkg_resources' and then use a 'require()' call similar to one of
> >these examples, in order to select the desired version:
> >
> >     pkg_resources.require("Cabochon")  # latest installed version
> >     pkg_resources.require("Cabochon==0.2dev-r19871")  # this exact
> >version
> >     pkg_resources.require("Cabochon>=0.2dev-r19871")  # this version or
> >higher
> >
> >
> >Note also that the installation directory must be on sys.path at runtime
> >for
> >this to work.  (e.g. by being the application's script directory, by
> >being on
> >PYTHONPATH, or by being added to sys.path by your code.)
> >[many more lines of this as it installs all the requirements]
> 
> 
> 
> 
> >5. Try to run
> >
> >(testve)$ paster
> >bash: paster: command not found
> >
> >6. Hm, that's no good.  Well, what if we just manually try to see if
> >stuff is installed:
> >
> >(testve)$ python
> >Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22)
> >[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
> >Type "help", "copyright", "credits" or "license" for more information.
> > >>> import cabochon
> >Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> >   File "cabochon/__init__.py", line 8, in <module>
> >     from cabochon.config.middleware import make_app
> >   File "cabochon/config/middleware.py", line 2, in <module>
> >     from paste import httpexceptions
> >ImportError: No module named paste
> >
> >Nope.
> 
> This didn't work because you only did half of what I said; you have 
> to do the -zmaxd step to load or update the cache, and the -af step 
> to actually install your target to the virtualenv.
> 


From pjenvey at underboss.org  Tue Aug 26 02:39:53 2008
From: pjenvey at underboss.org (Philip Jenvey)
Date: Mon, 25 Aug 2008 17:39:53 -0700
Subject: [Distutils] Testers wanted: about a dozen setuptools bugs
	closed in trunk
In-Reply-To: <20080825190125.3B8403A403D@sparrow.telecommunity.com>
References: <20080821200747.70C443A403D@sparrow.telecommunity.com>
	<A32557D8-94B0-4D56-B148-DF10DF14D142@underboss.org>
	<20080825190125.3B8403A403D@sparrow.telecommunity.com>
Message-ID: <BE706BBF-A907-41DD-B474-DFB9DCC08783@underboss.org>


On Aug 25, 2008, at 12:02 PM, Phillip J. Eby wrote:

> At 01:33 AM 8/23/2008 -0700, Philip Jenvey wrote:
>
>> On Aug 21, 2008, at 1:08 PM, Phillip J. Eby wrote:
>>
>>> I've checked in numerous fixes to bugs from the tracker today, with
>>> the intention to cut a c9 release on Monday.  Please update with
>>> "easy_install setuptools==dev", and try it out.  Thanks!
>>
>> Could you weigh in on my latest response/plea for: http://bugs.python.org/setuptools/issue27
>
> Yep: provide a (tested) patch that doesn't silently do the wrong  
> thing when command-line options are used.
>


Great, give me another day or so before the release for the updated  
patch.

--
Philip Jenvey



From matt at elyt.com  Tue Aug 26 23:54:49 2008
From: matt at elyt.com (Matt Halstead)
Date: Wed, 27 Aug 2008 09:54:49 +1200
Subject: [Distutils] versions and forward referencing options in recipe eggs
Message-ID: <8E8AA20F-6499-4765-93FE-2E7133D74BCE@elyt.com>

I have stumbled over a behaviour where the versions option is ignored  
in a particular scenario. I am wondering if this is intended behaviour  
or not.

The following is a simple example of a not very useful buildout. (this  
uses setuptools-0.6c8-py2.4 and zc.buildout-1.1.1-py2.4)

--------------

[buildout]
eggs-directory = ${buildout:directory}/eggs
download-cache = ${buildout:directory}/downloads

versions = versions

parts =
     plone

instance-base-eggs =
     ${plone:eggs}


[versions]
plone.recipe.plone = 3.1.4

[plone]
recipe = plone.recipe.plone

------------------------

When we define instance-base-eggs explicitly like this within the  
buildout section, then when the buildout bootstrap process is run  
(e.g. python2.4 bootstrap.py), the latest egg for plone.recipe.plone  
will be pulled and used to satisfy the recipe egg requirement when the  
buildout is run. The version in the versions section is ignored here.  
It is not ignored if the version is pinned directly to the  
plone.recipe.plone i.e. we have

[plone]
recipe = plone.recipe.plone == 3.1.4

If instead we have the following

------------------------

[buildout]
eggs-directory = ${buildout:directory}/eggs
download-cache = ${buildout:directory}/downloads

versions = versions

parts =
     plone

[base]
eggs =
     ${plone:eggs}


[versions]
plone.recipe.plone = 3.1.4

[plone]
recipe = plone.recipe.plone

--------------------------

Then the plone.recipe.plone egg is not pulled during the bootstrap  
process, but instead during the buildout process at which point the  
version pinning in the versions section is honored just fine.

Is it intended that the bootstrap process ignores versions in the  
versions section?

cheers
Matt




From setuptools at bugs.python.org  Wed Aug 27 01:55:47 2008
From: setuptools at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 26 Aug 2008 23:55:47 +0000
Subject: [Distutils] [issue36] warning about "module was already imported
	from"
In-Reply-To: <1219794947.71.0.54167696434.issue36@psf.upfronthosting.co.za>
Message-ID: <1219794947.71.0.54167696434.issue36@psf.upfronthosting.co.za>


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

/usr/lib/python2.5/site-packages/zope/__init__.py:19: UserWarning: Module
twisted was already imported from
/usr/lib/python2.5/site-packages/twisted/__init__.pyc, but
/home/buildslave/tahoe/feisty2.5/build/support/lib/python2.5/site-packages/Nevow-0.9.31-py2.5.egg
is being added to sys.path

Here is an example command line that yields this warning:

http://allmydata.org/buildbot/builders/feisty2.5/builds/1649/steps/pyflakes/logs/stdio

Note that this may be related to issue17 and issue20 -- why is the Nevow egg
declaring the "twisted" namespace and/or module anyway?

----------
messages: 136
nosy: zooko
priority: bug
status: unread
title: warning about "module was already imported from"

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

From setuptools at bugs.python.org  Thu Aug 28 23:50:51 2008
From: setuptools at bugs.python.org (Ian Bicking)
Date: Thu, 28 Aug 2008 21:50:51 +0000
Subject: [Distutils] [issue37] del __loader__ causes problems in appengine
In-Reply-To: <1219960251.36.0.769693674457.issue37@psf.upfronthosting.co.za>
Message-ID: <1219960251.36.0.769693674457.issue37@psf.upfronthosting.co.za>


New submission from Ian Bicking <ianb at colorstudy.com>:

Per this thread, the placeholder .py file created by setuptools can cause
problems when it deletes __loader__: http://markmail.org/message/qy2d6awkzcrr5t5s

----------
files: loader_bdist_egg.patch
messages: 148
nosy: ianb at colorstudy.com
priority: bug
status: unread
title: del __loader__ causes problems in appengine
Added file: http://bugs.python.org/setuptools/file19/loader_bdist_egg.patch

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue37>
_______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loader_bdist_egg.patch
Type: text/x-diff
Size: 716 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080828/b773306a/attachment.patch>

From setuptools at bugs.python.org  Fri Aug 29 00:16:58 2008
From: setuptools at bugs.python.org (Philip Jenvey)
Date: Thu, 28 Aug 2008 22:16:58 +0000
Subject: [Distutils] [issue38] bdist_egg extension stub loaders are broken
In-Reply-To: <1219961818.16.0.779997939706.issue38@psf.upfronthosting.co.za>
Message-ID: <1219961818.16.0.779997939706.issue38@psf.upfronthosting.co.za>


New submission from Philip Jenvey <pjenvey at underboss.org>:

There's two different stub loader generators in the code base: 
build_ext.write_stub and bdist_egg.write_stub

bdist_egg's stub loader always assumes the presence of a __loader__ value, which 
causes a NameError in some cases. build_ext's version of the stub loader does 
the right thing and only messes with __loader__ if it exists -- the following 
patch applys that check to bdist_egg's stub loader

This fix is particularly important for packages with optional C extensions 
deployed to Google App Engine (like simplejson, Genshi). Compiled extensions 
won't be imported by GAE (as they're not supported), so instead the stub loader 
is imported. Without a __loader__ present this results in:

File "/base/data/home/apps/sluggo-exp/2.1/lib/python2.5/site-
packages/simplejson-1.8.1-py2.5-macosx-10.3-i386.egg/simplejson/_speedups.py", 
line 5, in __bootstrap__
     del __bootstrap__, __loader__
 NameError: global name '__loader__' is not defined

instead of an ImportError, which these packages expect to be raised when they 
need to fallback to the alternative to the compiled extension

This should really make it in for the next release; prioritized as critical

----------
files: bdist_egg-stub-loader_r65963.diff
messages: 149
nosy: pjenvey
priority: critical
status: unread
title: bdist_egg extension stub loaders are broken
Added file: http://bugs.python.org/setuptools/file20/bdist_egg-stub-loader_r65963.diff

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue38>
_______________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bdist_egg-stub-loader_r65963.diff
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080828/a0701ab9/attachment.txt>

From zooko at zooko.com  Fri Aug 29 18:12:14 2008
From: zooko at zooko.com (zooko)
Date: Fri, 29 Aug 2008 10:12:14 -0600
Subject: [Distutils] "test_suite must be a list" ??
Message-ID: <439BAA43-F93D-43FA-84A7-CC483EA7F8A7@zooko.com>

I got a report from a user that he couldn't install my software  
because he got the error message "test_suite must be a list".

However, the version of setuptools that I have here asserts that  
test_suite must be a string.

He showed me that he has setuptools 0.6c8 installed.

Googling for "test_suite must be a list" suggests that maybe the  
Elisa project released a setuptools plugin to do something for unit  
tests which made that assertion.

I asked the user if he had installed any Elisa packages and he  
thought not.

For the moment, I commented-out the test_suite argument from my call  
to setup() and uploaded an interim version of my software which  
doesn't run its tests when you tell it "./setup.py test".  This is an  
unsatisfying solution.

Does anyone else have any knowledge of this problem?

Thanks!

Regards,

Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $5/month


From zooko at zooko.com  Fri Aug 29 19:02:45 2008
From: zooko at zooko.com (zooko)
Date: Fri, 29 Aug 2008 11:02:45 -0600
Subject: [Distutils] "test_suite must be a list" ??
In-Reply-To: <439BAA43-F93D-43FA-84A7-CC483EA7F8A7@zooko.com>
References: <439BAA43-F93D-43FA-84A7-CC483EA7F8A7@zooko.com>
Message-ID: <F5EC461B-E2CC-4D7E-9B38-B6233C6DFDF4@zooko.com>

Okay, folks, I confirmed that this was indeed because a package named  
"elisa" was installed on the user's system, and I added this work- 
around to my package's setup.py:

http://allmydata.org/trac/pycryptopp/browser/setup.py?rev=567#L146

146	try:
147	    _setup(test_suite="pycryptopp.test")
148	except BaseException, le:
149	    # to work around a bug in Elisa
150	    if "test_suite must be a list" in str(le):
151	        _setup(test_suite=["pycryptopp.test"])


This works on both my system (with setuptools 0.7 dev) and my user's  
system (with setuptools 0.6c8 and elisa).


I will try to contact the authors of elisa.


Regards,

Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $5/month


From srmandrake at yahoo.com  Fri Aug 29 20:07:28 2008
From: srmandrake at yahoo.com (SrMandrake ElMago)
Date: Fri, 29 Aug 2008 11:07:28 -0700 (PDT)
Subject: [Distutils] Do end-users need to install Python before
	installing/using Python extentions for a Windows program?
Message-ID: <862695.17237.qm@web56206.mail.re3.yahoo.com>

Hello,
I have developed a little Windows program that uses Python extensions I wrote myself (no SWIG or nothing), and I was wondering, if I am going to make this program run in a machine Windows, do I have to actually install?Python in this machine, if not, what are the minimum requirements.

Thanks in advance
Rod-


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080829/ffb0411f/attachment.htm>

From tarek.ziade at ingeniweb.com  Sat Aug 30 13:35:31 2008
From: tarek.ziade at ingeniweb.com (Tarek Ziade)
Date: Sat, 30 Aug 2008 13:35:31 +0200
Subject: [Distutils] Do end-users need to install Python before
	installing/using Python extentions for a Windows program?
In-Reply-To: <862695.17237.qm@web56206.mail.re3.yahoo.com>
References: <862695.17237.qm@web56206.mail.re3.yahoo.com>
Message-ID: <a26746990808300435n6b64b962vcb93f4e621f110e9@mail.gmail.com>

2008/8/29 SrMandrake ElMago <srmandrake at yahoo.com>

> Hello,
> I have developed a little Windows program that uses Python extensions I
> wrote myself (no SWIG or nothing), and I was wondering, if I am going to
> make this program run in a machine Windows, do I have to actually
> install Python in this machine, if not, what are the minimum requirements.
>
>

Hello

Yes you do, unless you use an embed Python to distribute your program, look
a the py2exe project for instance:

http://www.py2exe.org/

Regards

Tarek




> Thanks in advance
> Rod-
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>


-- 
Tarek Ziad? - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080830/8dc4b864/attachment.htm>