From mailing at franzoni.eu  Tue Jan  4 15:40:17 2011
From: mailing at franzoni.eu (Alan Franzoni)
Date: Tue, 4 Jan 2011 15:40:17 +0100
Subject: [Distutils] Distribute comments
In-Reply-To: <4D1B8F2E.5080506@noir.com>
References: <4D1B8F2E.5080506@noir.com>
Message-ID: <AANLkTi=bwDibahQiLLGWfqvyVaCOoWNsTvVBrx0YhOva@mail.gmail.com>

Hello,
have you just seen distribute guide - which is just an update fork of
the original setuptools distribution - or did you check out this as
well?:

http://guide.python-distribute.org/


Surely the setuptools/distribute fork has been painful so far, but
it's done. You could check out distutils2 as well.

-- 
Alan Franzoni
--
contact me at public@[mysurname].eu

From ziade.tarek at gmail.com  Tue Jan  4 16:13:13 2011
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 4 Jan 2011 16:13:13 +0100
Subject: [Distutils] Distribute comments
In-Reply-To: <4D1B8F2E.5080506@noir.com>
References: <4D1B8F2E.5080506@noir.com>
Message-ID: <AANLkTi=4eAq90JMVR5qvVmX_WXO4wux+aMBAmPGw85TH@mail.gmail.com>

On Wed, Dec 29, 2010 at 8:42 PM, K. Richard Pixley <rich at noir.com> wrote:
> I've just read through the Distribute doc for the first time and I have a
> few comments.
>
> First, I just want to say that the state of python packaging is a sad
> morass.? It's not easy for someone to sort out
> distutils/setuptools/distribute to figure out how to get a package built and
> released on pypi.? Distutils is official and available, but the
> documentation is only slightly relevant with much time and space given to
> features that aren't clear, aren't relevant, or don't solve today's
> problems.? Setuptools is messy, confusing, ill documented, and difficult to
> use.? The Distribute documentation helps in this considerably but it could
> be better.

The Distribute documentation is also taken from Setuptools, and
evolved a bit. But it still has probably some places that were not
updated.

>From a user point of view the major differences on the two projects are:

1. if Setuptools has a bug, it can be fixed in Distribute.
2. Distribute provides py3k compat and other features we needed, like
the easy_install --user option etc.
3. Distribute wants to provide a bridge for the upcoming Distutils2

So it's more a matter of "what installer do you need/want to install
?" -- on Ubuntu, Fedora, Gentoo and some other distros, Setuptools was
replaced by Distribute and this is transparent for you. On other
systems you can chose the one you want.

Note that the Distribute project is currently staled because most
people that work in it are now focusing on Distutils2. But if we hit
major bugs in Setuptools we will do new releases of Distribute. And it
welcomes contributions but lacks of reviewers + comitters right now.
It's easy to become one though, because the philosophy is to have more
people involved and to release it often.  By the way ,if someone want
to become the Distribute maintainer I'd be happy to pass it over while
focusing on Distutils2.

The Distutils2 project is actively developed and will be pushed back
in the stdlib sometimes after 3.2 final is out.


> The section on "What Your Users Should Know" sounds like the sort of
> information which has traditionally been released in an INSTALL file with
> GNU software.? Is there a reusable, sample template which explains this
> information in a package agnostic sort of way that I can simply include in
> my package?

No but the Guide pointed by Alan is where we wanted to provide this
kind of information.

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

From rich at noir.com  Tue Jan  4 18:37:28 2011
From: rich at noir.com (K. Richard Pixley)
Date: Tue, 04 Jan 2011 09:37:28 -0800
Subject: [Distutils] Distribute comments
In-Reply-To: <AANLkTi=bwDibahQiLLGWfqvyVaCOoWNsTvVBrx0YhOva@mail.gmail.com>
References: <4D1B8F2E.5080506@noir.com>
	<AANLkTi=bwDibahQiLLGWfqvyVaCOoWNsTvVBrx0YhOva@mail.gmail.com>
Message-ID: <4D235AD8.2020208@noir.com>

On 1/4/11 06:40 , Alan Franzoni wrote:
> Hello,
> have you just seen distribute guide - which is just an update fork of
> the original setuptools distribution - or did you check out this as
> well?:
>
> http://guide.python-distribute.org/
>
>
> Surely the setuptools/distribute fork has been painful so far, but
> it's done. You could check out distutils2 as well
Um... neither, I don't think.

I was commenting on this one: http://packages.python.org/distribute

The only "doc" I've seen for setuptools was pretty bad.  I don't find a 
copy of it now, though.

And I haven't yet seen a piece of overall documentation.  With at least 
three major efforts being involved, there really needs to be an 
overview, perhaps a HOWTO on python packaging.  Yes, I understand that 
it's politically charged, but right now it's pretty daunting.

--rich

From mailing at franzoni.eu  Tue Jan  4 19:12:25 2011
From: mailing at franzoni.eu (Alan Franzoni)
Date: Tue, 4 Jan 2011 19:12:25 +0100
Subject: [Distutils] Distribute comments
In-Reply-To: <4D235AD8.2020208@noir.com>
References: <4D1B8F2E.5080506@noir.com>
	<AANLkTi=bwDibahQiLLGWfqvyVaCOoWNsTvVBrx0YhOva@mail.gmail.com>
	<4D235AD8.2020208@noir.com>
Message-ID: <AANLkTintJow4kSayhx_BNyhyoh883t8kajmx0_8XqqtU@mail.gmail.com>

On Tue, Jan 4, 2011 at 6:37 PM, K. Richard Pixley <rich at noir.com> wrote:
>> http://guide.python-distribute.org

Look at that. You'll find it useful, even though it's still a work in progress.

> And I haven't yet seen a piece of overall documentation. ?With at least
> three major efforts being involved, there really needs to be an overview,
> perhaps a HOWTO on python packaging. ?Yes, I understand that it's
> politically charged, but right now it's pretty daunting.

You're right that sometimes python-related docs and best practices
can't be found easily, but work on that direction is being done. Feel
free to ask more questions if you need to.

-- 
Alan Franzoni
--
contact me at public@[mysurname].eu

From sienkiew at stsci.edu  Tue Jan  4 23:54:11 2011
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Tue, 04 Jan 2011 17:54:11 -0500
Subject: [Distutils] distutils and MSVCR90.DLL
Message-ID: <4D23A513.3080708@stsci.edu>

Hi,

I have a python package with C extensions.  In Python 2.5 on Windows, it works as expected.  In Python 2.7, it compiles and installs, but the import fails with:

ImportError: DLL load failed: The specified procedure could not be found.

I found a program called "Dependecy Walker" that tells me this about the .pyd file:

Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

It also says the missing library is MSVCR90.DLL which contains things like malloc and printf.  (It is also missing IESHIMS.DLL and WER.DLL but those are required by IEFRAME.DLL, so they may be a secondary problem.)

Apparently, MSVCR90 is a newer version of the C runtime library.  I have several copies of MSVCR71.DLL on my machine, but nothing named MSVCR90.DLL.

This leads to an obvious question:  How did I manage to compile C source code that depends on a shared library that is not even present on my machine?  I suspect it is because whoever built the Python distribution did it with a compiler that did have MSVCR90, and python remembered and told distutils.

Some web searching led me to find "vcredist_x86.exe" on Microsoft's web site, but installing that did not fix anything and did not create a file on my system name MSVCR90.DLL.  From http://support.microsoft.com/kb/326922 , I get the impression that MSVCR90.DLL should have been distributed with Python.  Or maybe not...

I'm about at the limit of my Windows expertise here.  Can anybody help?

Mark S.



From martin at v.loewis.de  Wed Jan  5 00:50:04 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 05 Jan 2011 00:50:04 +0100
Subject: [Distutils] distutils and MSVCR90.DLL
In-Reply-To: <4D23A513.3080708@stsci.edu>
References: <4D23A513.3080708@stsci.edu>
Message-ID: <4D23B22C.3000907@v.loewis.de>

> Apparently, MSVCR90 is a newer version of the C runtime library.  I have
> several copies of MSVCR71.DLL on my machine, but nothing named MSVCR90.DLL.

I'm pretty sure you do have this DLL: the Python installation came with
it. Check the WinSxS folder.

> Some web searching led me to find "vcredist_x86.exe" on Microsoft's web
> site, but installing that did not fix anything and did not create a file
> on my system name MSVCR90.DLL.

Most likely, it didn't because you had the file before. If you didn't
have it, it would have put it into the WinSxS folder.

Regards,
Martin

From sienkiew at stsci.edu  Wed Jan  5 20:12:46 2011
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Wed, 05 Jan 2011 14:12:46 -0500
Subject: [Distutils] distutils and MSVCR90.DLL
In-Reply-To: <4D23B22C.3000907@v.loewis.de>
References: <4D23A513.3080708@stsci.edu> <4D23B22C.3000907@v.loewis.de>
Message-ID: <4D24C2AE.7060904@stsci.edu>

Martin v. L?wis wrote:
>> Apparently, MSVCR90 is a newer version of the C runtime library.  I have
>> several copies of MSVCR71.DLL on my machine, but nothing named MSVCR90.DLL.
> 
> I'm pretty sure you do have this DLL: the Python installation came with
> it. Check the WinSxS folder.


You're right - I found these:

c:/Windows/WinSxS/x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375/msvcr90.dll
c:/Windows/WinSxS/x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e/msvcr90.dll

The modification time on the first one is March 26 2009, but the time on the second one is Jan 3 2011 15:30.  That would be around the time I was trying to install vcredist_x86.exe to fix the problem.

I still can't import the module, so if one of these DLLs is in the correct place, I can't trust the tool that tells me which DLL is missing.  In that case, how do I debug this?

>>> import calcos
Traceback (most recent call last):
...
  File "C:\Python27\lib\site-packages\calcos\cosutil.py", line 13, in <module>
    import ccos
ImportError: DLL load failed: The specified procedure could not be found.
>>>

Just to be sure, I've gone back and re-compiled it from clean source.  There is no indication of any compile errors, and it didn't make any difference.

Mark

From martin at v.loewis.de  Wed Jan  5 20:25:26 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 05 Jan 2011 20:25:26 +0100
Subject: [Distutils] distutils and MSVCR90.DLL
In-Reply-To: <4D24C2AE.7060904@stsci.edu>
References: <4D23A513.3080708@stsci.edu> <4D23B22C.3000907@v.loewis.de>
	<4D24C2AE.7060904@stsci.edu>
Message-ID: <4D24C5A6.7090706@v.loewis.de>


> ImportError: DLL load failed: The specified procedure could not be found.
>>>>
> 
> Just to be sure, I've gone back and re-compiled it from clean source. 
> There is no indication of any compile errors, and it didn't make any
> difference.

This is different from "DLL not found", though: it means that the DLL
*was* found, but doesn't have one of the symbols that is being used.
Unfortunately, it doesn't tell which symbol, and in which DLL.

> In that case, how do I debug this?

There are a number of ways:

1. load the pyd into depends.exe, and see whether it shows problems.
2. use sxstrace.exe

Regards,
Martin

From sienkiew at stsci.edu  Wed Jan  5 23:36:31 2011
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Wed, 05 Jan 2011 17:36:31 -0500
Subject: [Distutils] distutils and MSVCR90.DLL
In-Reply-To: <4D24C5A6.7090706@v.loewis.de>
References: <4D23A513.3080708@stsci.edu> <4D23B22C.3000907@v.loewis.de>
	<4D24C2AE.7060904@stsci.edu> <4D24C5A6.7090706@v.loewis.de>
Message-ID: <4D24F26F.6060903@stsci.edu>

Martin v. L?wis wrote:
>> ImportError: DLL load failed: The specified procedure could not be found.
>> Just to be sure, I've gone back and re-compiled it from clean source. 
>> There is no indication of any compile errors, and it didn't make any
>> difference.
> 
> This is different from "DLL not found", though: it means that the DLL
> *was* found, but doesn't have one of the symbols that is being used.
> Unfortunately, it doesn't tell which symbol, and in which DLL.

Thanks - that is useful to know.

> 
>> In that case, how do I debug this?
> 
> There are a number of ways:
> 
> 1. load the pyd into depends.exe, and see whether it shows problems.

depends.exe said "Error opening file.  The system cannot find the file specified (2)." about msvcr90.dll.  :(

> 2. use sxstrace.exe

Is there some documentation for it somewhere?  I'm not getting anything useful from start->help or google.


Maybe you can help me with a more general question:  My group writes python code (including c extensions) on linux/mac, then distribute a windows installer using distutils bdist_wininst.  The presumption is that you can expect to do that without Windows-specific development expertise.  Is that a realistic expectation?  

Mark

From martin at v.loewis.de  Thu Jan  6 00:13:05 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 06 Jan 2011 00:13:05 +0100
Subject: [Distutils] distutils and MSVCR90.DLL
In-Reply-To: <4D24F26F.6060903@stsci.edu>
References: <4D23A513.3080708@stsci.edu> <4D23B22C.3000907@v.loewis.de>
	<4D24C2AE.7060904@stsci.edu> <4D24C5A6.7090706@v.loewis.de>
	<4D24F26F.6060903@stsci.edu>
Message-ID: <4D24FB01.4040601@v.loewis.de>

> Maybe you can help me with a more general question:  My group writes
> python code (including c extensions) on linux/mac, then distribute a
> windows installer using distutils bdist_wininst.  The presumption is
> that you can expect to do that without Windows-specific development
> expertise.  Is that a realistic expectation? 

What compiler are you using? If it's not msvc, then no, this is not
a realistic expectation.

If you do build on Windows with the right MSC version, then you can
probably manage by paying someone once to set the build process up,
and then only running the build process. There is a good chance that
you break the Windows build every now and then, and then it will be
very time-consuming to diagnose the problem and fix it, without
expertise (roughly the same is probably true if you target any other
system without knowing what you are doing).

Regards,
Martin

From sridhar.ratna at gmail.com  Fri Jan  7 23:48:42 2011
From: sridhar.ratna at gmail.com (Sridhar)
Date: Fri, 7 Jan 2011 14:48:42 -0800
Subject: [Distutils] PEP 345: real-world examples of "virtual" projects
	(Provides-Release)
In-Reply-To: <4D2792E0.1000101@activestate.com>
References: <4D111F23.2040404@activestate.com> <4D147F6D.2040605@notmyidea.org>
	<4D2792E0.1000101@activestate.com>
Message-ID: <AANLkTikq1HfoYpQ95zZrhqY+9aY9XinJvXD5dDy8wAFP@mail.gmail.com>

Hi,

> From: Alexis M?taireau <alexis at notmyidea.org>
> On 12/21/2010 09:41 PM, Sridhar Ratnakumar wrote:
>>
>> 3. Did anyone--Alexis and Tarek, in particular--think of real-world use
>> cases for virtual projects (and even "provides" in general) other than
>> the Zope transaction case? If yes, what are they?
>
> "Provides-Release" lists the specific projects provided with this
> distribution. One case I can think about is having a distribution
> providing two different projects.
>
> A software can have a project for the "core" features and a project for
> the "default-plugins". It can then provides the two projects in only one
> distribution.
>
> Those can be two virtual projects 'core' and 'defaultplugins', which can
> be *provided* by different projects then. This allows to choose between
> the possible projects when resolving the dependencies.

What is the benefit of distributing two projects in a single
distribution, compared to the more simpler (traditional) solution of
distributing them in separate distributions  (and, optionally, making
one depend on another; eg: 'core' depend on 'defaultplugins')? Does
this benefit justify the cost of introducing a new metadata field?

> setuptools and distribute can be both provided by the same virtual project.

Is this the only real-world use of virtual projects? Are there
(potential) others?

>> 4. Personally, I have needs for "virtual" packages from a binary (not
>> source) distribution perspective. For example, "MySQL-python" can be a
>> virtual package "provided by" the binary distributions: mysql5.1-python,
>> mysql5.0-python;
> [...]
>> How would PEP 345's "Provides-Release" help, if at
>> all, in describing this scenario?
>
> I'm not sure it will help in this case, unfortunately.

Ok.

-Sridhar
ActiveState

From rafael at nexedi.com  Sun Jan  9 22:59:18 2011
From: rafael at nexedi.com (rafael at nexedi.com)
Date: Sun, 09 Jan 2011 22:59:18 +0100
Subject: [Distutils] buildout download cache
Message-ID: <20110109225918.143957xkisc2hghi@mail.tiolive.com>


Hi,

We are using extensively buildout to build ERP5 [1]:

  - https://svn.erp5.org/repos/public/erp5/trunk/buildout/

We are planning to extend buildout download API to provide a  
distributed automatic
packaging and caching system so that even if original source web site is down,
the buildout process can stil run. This could also be useful to build  
software in
secured networks.

Do you know of any similar project before we start?

[1] www.erp5.com

Regards,
Rafael Monnerat

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From marius at pov.lt  Mon Jan 10 08:50:16 2011
From: marius at pov.lt (Marius Gedminas)
Date: Mon, 10 Jan 2011 09:50:16 +0200
Subject: [Distutils] buildout download cache
In-Reply-To: <20110109225918.143957xkisc2hghi@mail.tiolive.com>
References: <20110109225918.143957xkisc2hghi@mail.tiolive.com>
Message-ID: <20110110075016.GA13086@fridge.pov.lt>

On Sun, Jan 09, 2011 at 10:59:18PM +0100, rafael at nexedi.com wrote:
> We are planning to extend buildout download API to provide a
> distributed automatic packaging and caching system so that even if
> original source web site is down, the buildout process can stil run.
> This could also be useful to build software in secured networks.
> 
> Do you know of any similar project before we start?

http://pypi.python.org/pypi/collective.eggproxy

(I haven't used it myself yet. When PyPI or original mirrors go down, I
can always find the necessary package in my development machine's
~/.buildout/cache/ and copy it over to where I need it -- because I've
set a global download-cache in ~/.buildout/default.cfg.)

Marius Gedminas
-- 
Computers are not intelligent.  They only think they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110110/b2069c62/attachment.pgp>

From rafael at nexedi.com  Mon Jan 10 12:28:51 2011
From: rafael at nexedi.com (rafael at nexedi.com)
Date: Mon, 10 Jan 2011 12:28:51 +0100
Subject: [Distutils] buildout download cache
In-Reply-To: <20110110075016.GA13086@fridge.pov.lt>
References: <20110109225918.143957xkisc2hghi@mail.tiolive.com>
	<20110110075016.GA13086@fridge.pov.lt>
Message-ID: <20110110122851.934173osrofz3i43@mail.tiolive.com>


Hi,

I give you a better explanation with a Use Case.

We would like to a solution not only for eggs download but for ALL  
kind of downloads that should be done by the buildout. For example  
haproxy setup [1]:

[haproxy]
recipe = hexagonit.recipe.cmmi
url = http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.9.tar.gz
md5sum = 2cbcc95b54c0d803edaa13e7b4aeec25

This recipe uses zc.buildout.download (standard buildout API) and  
requires this that url be online when you run buildout for the first  
time.

Considering that we get files from multiple source, we increase the  
changes that some service be offline, breaking the buildout setup.

The good approach for all downloads should be:

1st: Try Local cache (buildout download API already do this) which are  
not available in the first run.
2nd: Try original URL (buildout download API already do this)
3rd: Try a cache server or "network cache" (what we want to do or know  
if someone already did it)

This will guarantee that buildout could still running even original  
source is offline. It is also preferred that ALL recipes can use this  
network cache and be unified (or available) to download eggs too.

[1]  
https://svn.erp5.org/repos/public/erp5/trunk/buildout/software-profiles/haproxy.cfg

I beleave eggproxy is only usefull for eggs download, right?

Use global download-cache helps to share downloads between your builds  
but it do not help first time users.

Regards,
Rafael Monnerat

Quoting "Marius Gedminas" <marius at pov.lt>:

> On Sun, Jan 09, 2011 at 10:59:18PM +0100, rafael at nexedi.com wrote:
>> We are planning to extend buildout download API to provide a
>> distributed automatic packaging and caching system so that even if
>> original source web site is down, the buildout process can stil run.
>> This could also be useful to build software in secured networks.
>>
>> Do you know of any similar project before we start?
>
> http://pypi.python.org/pypi/collective.eggproxy
>
> (I haven't used it myself yet. When PyPI or original mirrors go down, I
> can always find the necessary package in my development machine's
> ~/.buildout/cache/ and copy it over to where I need it -- because I've
> set a global download-cache in ~/.buildout/default.cfg.)
>
> Marius Gedminas
> --
> Computers are not intelligent.  They only think they are.
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

From thomas at thomas-lotze.de  Tue Jan 11 09:03:36 2011
From: thomas at thomas-lotze.de (Thomas Lotze)
Date: Tue, 11 Jan 2011 09:03:36 +0100
Subject: [Distutils] buildout download cache
References: <20110109225918.143957xkisc2hghi@mail.tiolive.com>
Message-ID: <pan.2011.01.11.08.03.35.802885@ID-174572.user.uni-berlin.de>

rafael wrote:

> We are planning to extend buildout download API to provide a distributed
> automatic
> packaging and caching system so that even if original source web site is
> down, the buildout process can stil run. This could also be useful to
> build software in
> secured networks.

I'd strongly suggest keeping this logic out of the download API. It sounds
like something that may potentially grow a lot more complex than a simple
"download this URL, with or without using a cache" gesture.

In my opinion, a distributed packaging system is application logic from
the perspective of a generic framework such as zc.buildout. It might be
implemented by a recipe, some library on top of the download API or some
other mechanism altogether, but it should neither complicate the semantics
of the existing download API nor add a new one to the zc.buildout code
base.

-- 
Thomas




From mailing at franzoni.eu  Tue Jan 11 12:51:53 2011
From: mailing at franzoni.eu (Alan Franzoni)
Date: Tue, 11 Jan 2011 12:51:53 +0100
Subject: [Distutils] Setting version from commandline or setup.cfg?
Message-ID: <AANLkTimqEEbgPf-xN1zYK1gUtFqpQqMnzXYyPW-mxXcD@mail.gmail.com>

Hello,
I'm trying to automate my release process from vcs - something like:

run tests ->
 fetch current major, minor from branch (e.g. release_1.2) and
revision from tag (e.g. v1.2.1) ->
upload with current major, minor and  revision +1 >
tag with such current major, minor and incremented revision.


I'd like to set my version from outside my setup.py file, either via
setup.py or a commandline option - I don't want to execute code in my
setup.py since this usually causes all sort of headaches with missing
dependencies.

Is there any proper way to do it? Might I break  other things unexpectedly?

-- 
Alan Franzoni
--
contact me at public@[mysurname].eu

From m.van.rees at zestsoftware.nl  Tue Jan 11 14:41:11 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Tue, 11 Jan 2011 14:41:11 +0100
Subject: [Distutils] Setting version from commandline or setup.cfg?
In-Reply-To: <AANLkTimqEEbgPf-xN1zYK1gUtFqpQqMnzXYyPW-mxXcD@mail.gmail.com>
References: <AANLkTimqEEbgPf-xN1zYK1gUtFqpQqMnzXYyPW-mxXcD@mail.gmail.com>
Message-ID: <ighmln$m1p$1@dough.gmane.org>

Op 11-01-11 12:51, Alan Franzoni schreef:
> Hello,
> I'm trying to automate my release process from vcs - something like:
>
> run tests ->
>   fetch current major, minor from branch (e.g. release_1.2) and
> revision from tag (e.g. v1.2.1) ->
> upload with current major, minor and  revision +1>
> tag with such current major, minor and incremented revision.
>
>
> I'd like to set my version from outside my setup.py file, either via
> setup.py or a commandline option - I don't want to execute code in my
> setup.py since this usually causes all sort of headaches with missing
> dependencies.
>
> Is there any proper way to do it? Might I break  other things unexpectedly?

I suggest using a tool like:
http://pypi.python.org/pypi/zest.releaser
http://pypi.python.org/pypi/jarn.mkrelease
http://pypi.python.org/pypi/collective.releaser

Depending on which vcs you are using you may need some extra packages, see:
http://pypi.python.org/pypi/zest.releaser/3.18#prepare-for-pypi-distribution


When testing any of these tools you may want to create a local 
subversion/git/mercurial/whatever repository and create a small package 
there to test releasing it.


-- 
Maurits van Rees
Programmer at Zest Software http://zestsoftware.nl
Personal website http://maurits.vanrees.org/


From cool-rr at cool-rr.com  Wed Jan 12 20:31:39 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Wed, 12 Jan 2011 21:31:39 +0200
Subject: [Distutils] .exe for script in Windows doesn't work
Message-ID: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.com>

Hi guys,

I made a release of my project today, and now I see there's something wrong
with it.

When you install it on Windows using the windows binaries (that I made with
`bdist_msi` under Python 2.7), the .exe scripts in the "Scripts" folder
don't work. When you launch them, nothing happens. You can launch the
associated *-script.pyw files and those *do* work.

I investigated a little and possibly I figured it out. The shebang line says
"#!c:\Python27\pythonw.exe". This is the interpreter with which I *created*
the binaries. But why should it be the interpreter with which the *user*
works? The user could have "c:\Python26\pythonw.exe" as his interpreter
or "c:\Programs\Python25\pythonw.exe" or "g:\Pypy\pypy.exe" as his
interpreter.

I tried editing the shebang line with notepad, and this caused the exe files
to start working! (Of course this is not a real solution, I can't ask my
users to do that.)

Is this a bug in distribute?

I'd appreciate if you can reply soon since I already started the release
process and I don't want to confuse users.


Thanks,
Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110112/f34c768e/attachment.html>

From jjkunce at gmail.com  Wed Jan 12 23:33:44 2011
From: jjkunce at gmail.com (Jeff Kunce)
Date: Wed, 12 Jan 2011 17:33:44 -0500
Subject: [Distutils] buildout pinning versions and egg requires
Message-ID: <AANLkTikkEN63L8_-nEpVihRvQNw5HnHu7E=nJrE6Cfn_@mail.gmail.com>

Hi -

I'm having trouble pinning versions in my buildout.  It looks like
"requires.txt" for the recipe eggs are overriding what I specify in
versions.cfg.

Here's the scenario:

  1)  I am pinning my buildout with a versions.cfg file that specifies
    zope2 = 2.13.0
  2) One of my parts is based on
    recipe = plone.recipe.zope2instance
  3) The plone.recipe.zope2instance egg has a requires.txt file containing
    Zope2 >= 2.12.1

Here's what happens:

When I run buildout, it looks the recipe eggs are downloaded first, along
with eggs specified in the requires.txt for each egg.  So, buildout gets
Zope2 2.13.1 (>=2.12.1) for plone.recipe.zope2instance without looking at
what I specified for versions.

How can I make sure I only get Zope 2.13.0 ?  An excerpt of my buildout.cfg
is below.  Thanks.

  -- Jeff

[buildout]
...
extends = versions.cfg
versions = versions
...
parts = mydeps zeo inst1 inst2 inst3 inst4 myproducts siteconfig

[mydeps]
...
[inst1]
recipe = plone.recipe.zope2instance
zeo-client = true
...
[inst2]
...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110112/3694e60e/attachment.html>

From m.van.rees at zestsoftware.nl  Thu Jan 13 00:38:15 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Thu, 13 Jan 2011 00:38:15 +0100
Subject: [Distutils] buildout pinning versions and egg requires
In-Reply-To: <AANLkTikkEN63L8_-nEpVihRvQNw5HnHu7E=nJrE6Cfn_@mail.gmail.com>
References: <AANLkTikkEN63L8_-nEpVihRvQNw5HnHu7E=nJrE6Cfn_@mail.gmail.com>
Message-ID: <igle17$sbv$1@dough.gmane.org>

Op 12-01-11 23:33, Jeff Kunce schreef:
> Hi -
>
> I'm having trouble pinning versions in my buildout.  It looks like
> "requires.txt" for the recipe eggs are overriding what I specify in
> versions.cfg.
>
> Here's the scenario:
>
>    1)  I am pinning my buildout with a versions.cfg file that specifies
>      zope2 = 2.13.0
>    2) One of my parts is based on
>      recipe = plone.recipe.zope2instance
>    3) The plone.recipe.zope2instance egg has a requires.txt file containing
>      Zope2 >= 2.12.1
>
> Here's what happens:
>
> When I run buildout, it looks the recipe eggs are downloaded first,
> along with eggs specified in the requires.txt for each egg.  So,
> buildout gets Zope2 2.13.1 (>=2.12.1) for plone.recipe.zope2instance
> without looking at what I specified for versions.
>
> How can I make sure I only get Zope 2.13.0 ?  An excerpt of my
> buildout.cfg is below.  Thanks.

Looks like you have a typo in the version pin: it should be Zope2 with a 
capital 'Z'.

This small buildout.cfg correctly picks Zope2 2.13.0 when I try it:

[buildout]
parts = instance
versions = versions

[versions]
Zope2 = 2.13.0

[instance]
recipe = plone.recipe.zope2instance

Note that to avoid such problems with uppercase versus lowercase, you 
could use a buildout extension that on the fly turns all version pins to 
lowercase when checking if a package has a pin:

[buildout]
extensions = buildout-versions

It also dumps which versions are picked by buildout instead of being 
pinned by you in buildout.cfg.


-- 
Maurits van Rees
Programmer at Zest Software http://zestsoftware.nl
Personal website http://maurits.vanrees.org/


From pje at telecommunity.com  Thu Jan 13 01:25:48 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 12 Jan 2011 19:25:48 -0500
Subject: [Distutils] .exe for script in Windows doesn't work
In-Reply-To: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.c
 om>
References: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.com>
Message-ID: <20110113002558.C63DE3A4065@sparrow.telecommunity.com>

At 09:31 PM 1/12/2011 +0200, cool-RR wrote:
>Hi guys,
>
>I made a release of my project today, and now I see there's 
>something wrong with it.
>
>When you install it on Windows using the windows binaries (that I 
>made with `bdist_msi` under Python 2.7), the .exe scripts in the 
>"Scripts" folder don't work. When you launch them, nothing happens. 
>You can launch the associated *-script.pyw files and those *do* work.
>
>I investigated a little and possibly I figured it out. The shebang 
>line says "#!c:\Python27\pythonw.exe". This is the interpreter with 
>which I *created* the binaries. But why should it be the interpreter 
>with which the *user* works? The user could have 
>"c:\Python26\pythonw.exe" as his interpreter or 
>"c:\Programs\Python25\pythonw.exe" or "g:\Pypy\pypy.exe" as his interpreter.
>
>I tried editing the shebang line with notepad, and this caused the 
>exe files to start working! (Of course this is not a real solution, 
>I can't ask my users to do that.)
>
>Is this a bug in distribute?

It's a limitation of setuptools+bdist_msi - when you build a 
bdist_wininst, setuptools writes a generic #! line, but when you 
build a bdist_msi, it doesn't realize you're building a distribution.


>I'd appreciate if you can reply soon since I already started the 
>release process and I don't want to confuse users.

As a quick workaround, you could try setting sys.executable to 
'pythonw.exe' in your setup.py, *before* setuptools is imported, then 
build the .msi.


From cool-rr at cool-rr.com  Thu Jan 13 08:54:47 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Thu, 13 Jan 2011 09:54:47 +0200
Subject: [Distutils] .exe for script in Windows doesn't work
In-Reply-To: <20110113002558.C63DE3A4065@sparrow.telecommunity.com>
References: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.com>
	<20110113002558.C63DE3A4065@sparrow.telecommunity.com>
Message-ID: <AANLkTikf7nZemFNDyszFA42F+nqAEvHa7uVE5DTkGEga@mail.gmail.com>

On Thu, Jan 13, 2011 at 2:25 AM, P.J. Eby <pje at telecommunity.com> wrote:

> At 09:31 PM 1/12/2011 +0200, cool-RR wrote:
>
>> Hi guys,
>>
>> I made a release of my project today, and now I see there's something
>> wrong with it.
>>
>> When you install it on Windows using the windows binaries (that I made
>> with `bdist_msi` under Python 2.7), the .exe scripts in the "Scripts" folder
>> don't work. When you launch them, nothing happens. You can launch the
>> associated *-script.pyw files and those *do* work.
>>
>> I investigated a little and possibly I figured it out. The shebang line
>> says "#!c:\Python27\pythonw.exe". This is the interpreter with which I
>> *created* the binaries. But why should it be the interpreter with which the
>> *user* works? The user could have "c:\Python26\pythonw.exe" as his
>> interpreter or "c:\Programs\Python25\pythonw.exe" or "g:\Pypy\pypy.exe" as
>> his interpreter.
>>
>> I tried editing the shebang line with notepad, and this caused the exe
>> files to start working! (Of course this is not a real solution, I can't ask
>> my users to do that.)
>>
>> Is this a bug in distribute?
>>
>
> It's a limitation of setuptools+bdist_msi - when you build a bdist_wininst,
> setuptools writes a generic #! line, but when you build a bdist_msi, it
> doesn't realize you're building a distribution.


So which project exactly is responsible for this limitation? Distribute?

Do you think there's a good reason not to have the MSI put the path to
python.exe itself into the shebang upon installation?


>  I'd appreciate if you can reply soon since I already started the release
>> process and I don't want to confuse users.
>>
>
> As a quick workaround, you could try setting sys.executable to
> 'pythonw.exe' in your setup.py, *before* setuptools is imported, then build
> the .msi.
>

I'd be reluctant to do that, since many users don't have the Python folder
on their PATH, so it won't work for them at all.


Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110113/6982a38d/attachment-0001.html>

From k.bx at ya.ru  Thu Jan 13 11:45:46 2011
From: k.bx at ya.ru (kost BebiX)
Date: Thu, 13 Jan 2011 12:45:46 +0200
Subject: [Distutils] simpler distutils.cmd.Command
Message-ID: <366621294915547@web31.yandex.ru>

hi!
I am really confused about all the setuptools/distutils/distribute/distutils2/easy_install/pip situation, but still have a little frustration about writing your own command for python setup.py your_command_name.

Right now, for example, babel package provides it's command::

    python setup.py extract_messages

To do that, the part::

    [distutils.commands]
    extract_messages = babel.messages.frontend:extract_messages

is ok, but what I dislike is the whole::

    from distutils.cmd import Command
    
    class extract_messages(Command):
        # provide user_options and 3 more function implementations in here
        pass

thing. I find it really implicit.

I mean, how do I run the command extract_messages from python? Maybe implementation of command should be that it can be called from regular python code like::

    extract_messages(my_custom_kwargs=here)

?

-- 
jabber: k.bx at ya.ru

From benji at benjiyork.com  Thu Jan 13 15:27:29 2011
From: benji at benjiyork.com (Benji York)
Date: Thu, 13 Jan 2011 09:27:29 -0500
Subject: [Distutils] buildout pinning versions and egg requires
In-Reply-To: <igle17$sbv$1@dough.gmane.org>
References: <AANLkTikkEN63L8_-nEpVihRvQNw5HnHu7E=nJrE6Cfn_@mail.gmail.com>
	<igle17$sbv$1@dough.gmane.org>
Message-ID: <AANLkTi=1GEz372fnNwQL=tm4c=ungoK8jCpJ2Kpmqv=1@mail.gmail.com>

On Wed, Jan 12, 2011 at 6:38 PM, Maurits van Rees
<m.van.rees at zestsoftware.nl> wrote:
> Op 12-01-11 23:33, Jeff Kunce schreef:
>>
>> I'm having trouble pinning versions in my buildout. ?It looks like
>> "requires.txt" for the recipe eggs are overriding what I specify in
>> versions.cfg.
>
> Looks like you have a typo in the version pin: it should be Zope2 with a
> capital 'Z'.

Adding allow-picked-versions = false to your [buildout] section can help
keep this from happening.
-- 
Benji York

From pje at telecommunity.com  Thu Jan 13 16:11:36 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 13 Jan 2011 10:11:36 -0500
Subject: [Distutils] .exe for script in Windows doesn't work
In-Reply-To: <AANLkTikf7nZemFNDyszFA42F+nqAEvHa7uVE5DTkGEga@mail.gmail.c
 om>
References: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.com>
	<20110113002558.C63DE3A4065@sparrow.telecommunity.com>
	<AANLkTikf7nZemFNDyszFA42F+nqAEvHa7uVE5DTkGEga@mail.gmail.com>
Message-ID: <20110113151149.2C5113A48BF@sparrow.telecommunity.com>

At 09:54 AM 1/13/2011 +0200, cool-RR wrote:
>On Thu, Jan 13, 2011 at 2:25 AM, P.J. Eby 
><<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:
>At 09:31 PM 1/12/2011 +0200, cool-RR wrote:
>Hi guys,
>
>I made a release of my project today, and now I see there's 
>something wrong with it.
>
>When you install it on Windows using the windows binaries (that I 
>made with `bdist_msi` under Python 2.7), the .exe scripts in the 
>"Scripts" folder don't work. When you launch them, nothing happens. 
>You can launch the associated *-script.pyw files and those *do* work.
>
>I investigated a little and possibly I figured it out. The shebang 
>line says "#!c:\Python27\pythonw.exe". This is the interpreter with 
>which I *created* the binaries. But why should it be the interpreter 
>with which the *user* works? The user could have 
>"c:\Python26\pythonw.exe" as his interpreter or 
>"c:\Programs\Python25\pythonw.exe" or "g:\Pypy\pypy.exe" as his interpreter.
>
>I tried editing the shebang line with notepad, and this caused the 
>exe files to start working! (Of course this is not a real solution, 
>I can't ask my users to do that.)
>
>Is this a bug in distribute?
>
>
>It's a limitation of setuptools+bdist_msi - when you build a 
>bdist_wininst, setuptools writes a generic #! line, but when you 
>build a bdist_msi, it doesn't realize you're building a distribution.
>
>
>So which project exactly is responsible for this limitation? Distribute?

Setuptools.


>Do you think there's a good reason not to have the MSI put the path 
>to python.exe itself into the shebang upon installation?

I don't know how to have bdist_msi do that.  Do you?


>As a quick workaround, you could try setting sys.executable to 
>'pythonw.exe' in your setup.py, *before* setuptools is imported, 
>then build the .msi.
>
>
>I'd be reluctant to do that, since many users don't have the Python 
>folder on their PATH, so it won't work for them at all.

That's not how it works.  When the #! line doesn't contain an 
absolute path, the .exe stub looks in the parent directory relative 
to where the script was installed.  So, as long as the .exe and .pyw 
are in an immediate subdirectory of the Python directory (usually 
Scripts), it will work correctly.


From jjkunce at gmail.com  Thu Jan 13 17:00:40 2011
From: jjkunce at gmail.com (Jeff Kunce)
Date: Thu, 13 Jan 2011 11:00:40 -0500
Subject: [Distutils] buildout pinning versions and egg requires
In-Reply-To: <igle17$sbv$1@dough.gmane.org>
References: <AANLkTikkEN63L8_-nEpVihRvQNw5HnHu7E=nJrE6Cfn_@mail.gmail.com>
	<igle17$sbv$1@dough.gmane.org>
Message-ID: <AANLkTinhSuuvFhFRXmAhViawzjTtcFYhi33BcBPjRS9X@mail.gmail.com>

Thanks Maurits (and Benji) -

That explains a lot.  We are running on windows, and our versions.cfg was
generated by buildout.dumppickedversions - it looks like everything in that
file is all lower case.  Your suggestions will be very useful.

  -- Jeff

On Wed, Jan 12, 2011 at 6:38 PM, Maurits van Rees <
m.van.rees at zestsoftware.nl> wrote:

> Op 12-01-11 23:33, Jeff Kunce schreef:
>
>  Hi -
>>
>> I'm having trouble pinning versions in my buildout.  It looks like
>> "requires.txt" for the recipe eggs are overriding what I specify in
>> versions.cfg.
>>
>> Here's the scenario:
>>
>>   1)  I am pinning my buildout with a versions.cfg file that specifies
>>     zope2 = 2.13.0
>>   2) One of my parts is based on
>>     recipe = plone.recipe.zope2instance
>>   3) The plone.recipe.zope2instance egg has a requires.txt file containing
>>     Zope2 >= 2.12.1
>>
>> Here's what happens:
>>
>> When I run buildout, it looks the recipe eggs are downloaded first,
>> along with eggs specified in the requires.txt for each egg.  So,
>> buildout gets Zope2 2.13.1 (>=2.12.1) for plone.recipe.zope2instance
>> without looking at what I specified for versions.
>>
>> How can I make sure I only get Zope 2.13.0 ?  An excerpt of my
>> buildout.cfg is below.  Thanks.
>>
>
> Looks like you have a typo in the version pin: it should be Zope2 with a
> capital 'Z'.
>
> This small buildout.cfg correctly picks Zope2 2.13.0 when I try it:
>
> [buildout]
> parts = instance
> versions = versions
>
> [versions]
> Zope2 = 2.13.0
>
> [instance]
> recipe = plone.recipe.zope2instance
>
> Note that to avoid such problems with uppercase versus lowercase, you could
> use a buildout extension that on the fly turns all version pins to lowercase
> when checking if a package has a pin:
>
> [buildout]
> extensions = buildout-versions
>
> It also dumps which versions are picked by buildout instead of being pinned
> by you in buildout.cfg.
>
>
> --
> Maurits van Rees
> Programmer at Zest Software http://zestsoftware.nl
> Personal website http://maurits.vanrees.org/
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110113/1a07d051/attachment.html>

From cool-rr at cool-rr.com  Thu Jan 13 21:27:38 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Thu, 13 Jan 2011 22:27:38 +0200
Subject: [Distutils] .exe for script in Windows doesn't work
In-Reply-To: <20110113151149.2C5113A48BF@sparrow.telecommunity.com>
References: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.com>
	<20110113002558.C63DE3A4065@sparrow.telecommunity.com>
	<AANLkTikf7nZemFNDyszFA42F+nqAEvHa7uVE5DTkGEga@mail.gmail.com>
	<20110113151149.2C5113A48BF@sparrow.telecommunity.com>
Message-ID: <AANLkTikxBox5evcRSaoG+d7w7m0rVcOKCCtQfYACZcso@mail.gmail.com>

On Thu, Jan 13, 2011 at 5:11 PM, P.J. Eby <pje at telecommunity.com> wrote:

> At 09:54 AM 1/13/2011 +0200, cool-RR wrote:
>
>  On Thu, Jan 13, 2011 at 2:25 AM, P.J. Eby <<mailto:pje at telecommunity.com>
>> pje at telecommunity.com> wrote:
>> At 09:31 PM 1/12/2011 +0200, cool-RR wrote:
>> Hi guys,
>>
>> I made a release of my project today, and now I see there's something
>> wrong with it.
>>
>> When you install it on Windows using the windows binaries (that I made
>> with `bdist_msi` under Python 2.7), the .exe scripts in the "Scripts" folder
>> don't work. When you launch them, nothing happens. You can launch the
>> associated *-script.pyw files and those *do* work.
>>
>> I investigated a little and possibly I figured it out. The shebang line
>> says "#!c:\Python27\pythonw.exe". This is the interpreter with which I
>> *created* the binaries. But why should it be the interpreter with which the
>> *user* works? The user could have "c:\Python26\pythonw.exe" as his
>> interpreter or "c:\Programs\Python25\pythonw.exe" or "g:\Pypy\pypy.exe" as
>> his interpreter.
>>
>> I tried editing the shebang line with notepad, and this caused the exe
>> files to start working! (Of course this is not a real solution, I can't ask
>> my users to do that.)
>>
>> Is this a bug in distribute?
>>
>>
>> It's a limitation of setuptools+bdist_msi - when you build a
>> bdist_wininst, setuptools writes a generic #! line, but when you build a
>> bdist_msi, it doesn't realize you're building a distribution.
>>
>>
>> So which project exactly is responsible for this limitation? Distribute?
>>
>
> Setuptools.


I don't understand; Isn't this one of the things that `distribute` has
control of? I mean, I generate the MSI in a computer that has distribute
installed. (IIUC, when I import `setuptools` on this computer, it uses the
distribute code.) Am I wrong in one of my assumptions.



 Do you think there's a good reason not to have the MSI put the path to
>> python.exe itself into the shebang upon installation?
>>
>
> I don't know how to have bdist_msi do that.  Do you?


No, I have no idea how MSIs are generated at all. I didn't ask if you
specifically know how to do it, just if you think there's a good reason not
to put this feature. (e.g., it will cause a problem in some cases that I
didn't think of.)

Who is maintaining bdist_msi?



>  As a quick workaround, you could try setting sys.executable to
>> 'pythonw.exe' in your setup.py, *before* setuptools is imported, then build
>> the .msi.
>>
>>
>> I'd be reluctant to do that, since many users don't have the Python folder
>> on their PATH, so it won't work for them at all.
>>
>
> That's not how it works.  When the #! line doesn't contain an absolute
> path, the .exe stub looks in the parent directory relative to where the
> script was installed.  So, as long as the .exe and .pyw are in an immediate
> subdirectory of the Python directory (usually Scripts), it will work
> correctly.
>

Ah, not bad. Thanks.


Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110113/aef99e2e/attachment-0001.html>

From martin at v.loewis.de  Thu Jan 13 22:26:52 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 13 Jan 2011 22:26:52 +0100
Subject: [Distutils] .exe for script in Windows doesn't work
In-Reply-To: <AANLkTikxBox5evcRSaoG+d7w7m0rVcOKCCtQfYACZcso@mail.gmail.com>
References: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.com>	<20110113002558.C63DE3A4065@sparrow.telecommunity.com>	<AANLkTikf7nZemFNDyszFA42F+nqAEvHa7uVE5DTkGEga@mail.gmail.com>	<20110113151149.2C5113A48BF@sparrow.telecommunity.com>
	<AANLkTikxBox5evcRSaoG+d7w7m0rVcOKCCtQfYACZcso@mail.gmail.com>
Message-ID: <4D2F6E1C.3050001@v.loewis.de>

> Who is maintaining bdist_msi?

I am. Unfortunately, I don't even understand the problem you are talking
about, let alone being able to do anything about it.

Regards,
Martin

From cool-rr at cool-rr.com  Thu Jan 13 22:35:20 2011
From: cool-rr at cool-rr.com (cool-RR)
Date: Thu, 13 Jan 2011 23:35:20 +0200
Subject: [Distutils] .exe for script in Windows doesn't work
In-Reply-To: <4D2F6E1C.3050001@v.loewis.de>
References: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.com>
	<20110113002558.C63DE3A4065@sparrow.telecommunity.com>
	<AANLkTikf7nZemFNDyszFA42F+nqAEvHa7uVE5DTkGEga@mail.gmail.com>
	<20110113151149.2C5113A48BF@sparrow.telecommunity.com>
	<AANLkTikxBox5evcRSaoG+d7w7m0rVcOKCCtQfYACZcso@mail.gmail.com>
	<4D2F6E1C.3050001@v.loewis.de>
Message-ID: <AANLkTik01532D63NLhp9bVxKdLGrF=_Rxkt8qxThov=F@mail.gmail.com>

On Thu, Jan 13, 2011 at 11:26 PM, "Martin v. L?wis" <martin at v.loewis.de>wrote:

> > Who is maintaining bdist_msi?
>
> I am. Unfortunately, I don't even understand the problem you are talking
> about, let alone being able to do anything about it.
>
> Regards,
> Martin
>

I'll explain. (Please correct me if I'm making any mistakes here.)

When you install a Python package in Windows, an .exe file is generated for
every script that your package defines. This .exe file sits alongside the
.py scripts in the PythonXX\Scripts folder. The .exe file launches the
Python interpreter with the Python script. The .exe file needs to know where
your Python interpreter is, and it uses the shebang line on the script file
to do it, like this: "#!c:\Python27\pythonw.exe"

Problem is, that instead of specifying the interpreter of the system on
which you're installing, it's using the interpreter of the system which
generated the bdist_msi. So since I generated MSI with Python 2.7, the
shebang line showed a path to a Python 2.7 installation. This is a problem
since the user might have Python 2.6 installed, or he can have Python
installed in a non-default path, etc.

What seems right to me is that the MSI installer will figure out where the
Python interpreter is on the end-user's system and then use that in the
shebang line.

What do you think?


Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110113/966d6d6e/attachment.html>

From martin at v.loewis.de  Thu Jan 13 22:45:43 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 13 Jan 2011 22:45:43 +0100
Subject: [Distutils] .exe for script in Windows doesn't work
In-Reply-To: <AANLkTik01532D63NLhp9bVxKdLGrF=_Rxkt8qxThov=F@mail.gmail.com>
References: <AANLkTinSKggceGtx6-S78-CPYTwQd0yOd5wyCqo5J2An@mail.gmail.com>	<20110113002558.C63DE3A4065@sparrow.telecommunity.com>	<AANLkTikf7nZemFNDyszFA42F+nqAEvHa7uVE5DTkGEga@mail.gmail.com>	<20110113151149.2C5113A48BF@sparrow.telecommunity.com>	<AANLkTikxBox5evcRSaoG+d7w7m0rVcOKCCtQfYACZcso@mail.gmail.com>	<4D2F6E1C.3050001@v.loewis.de>
	<AANLkTik01532D63NLhp9bVxKdLGrF=_Rxkt8qxThov=F@mail.gmail.com>
Message-ID: <4D2F7287.9050309@v.loewis.de>

>     I am. Unfortunately, I don't even understand the problem you are talking
>     about, let alone being able to do anything about it.
> 
>     Regards,
>     Martin
> 
> 
> I'll explain. (Please correct me if I'm making any mistakes here.)
> 
> When you install a Python package in Windows, an .exe file is generated
> for every script that your package defines.

How is that generated (i.e. what piece of code specifically generates it)?

> What seems right to me is that the MSI installer will figure out where
> the Python interpreter is on the end-user's system and then use that in
> the shebang line.
> 
> What do you think?

That will be difficult. It will require a custom action to be generated
when the MSI is produced, and that custom action must be scheduled into
the InstallExecute sequence.

Regards,
Martin

From pje at telecommunity.com  Fri Jan 14 05:23:28 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 13 Jan 2011 23:23:28 -0500
Subject: [Distutils] .exe for script in Windows doesn't work
Message-ID: <20110114042342.2A7C83A40F5@sparrow.telecommunity.com>

At 10:45 PM 1/13/2011 +0100, Martin v. L?wis wrote:
>How is that generated (i.e. what piece of code specifically generates it)?

See setuptools.command.install_scripts.run() - it makes .exe and 
-script.py/-script.pyw files.  It has some hackery to detect 
bdist_wininst and use a relative #! line in that case, but it doesn't 
have equivalent hackery for bdist_msi.


From marius at pov.lt  Fri Jan 14 12:17:12 2011
From: marius at pov.lt (Marius Gedminas)
Date: Fri, 14 Jan 2011 13:17:12 +0200
Subject: [Distutils] buildout pinning versions and egg requires
In-Reply-To: <AANLkTinhSuuvFhFRXmAhViawzjTtcFYhi33BcBPjRS9X@mail.gmail.com>
References: <AANLkTikkEN63L8_-nEpVihRvQNw5HnHu7E=nJrE6Cfn_@mail.gmail.com>
	<igle17$sbv$1@dough.gmane.org>
	<AANLkTinhSuuvFhFRXmAhViawzjTtcFYhi33BcBPjRS9X@mail.gmail.com>
Message-ID: <20110114111712.GB7599@fridge.pov.lt>

On Thu, Jan 13, 2011 at 11:00:40AM -0500, Jeff Kunce wrote:
> Thanks Maurits (and Benji) -
> 
> That explains a lot.  We are running on windows, and our versions.cfg was
> generated by buildout.dumppickedversions - it looks like everything in that
> file is all lower case.  Your suggestions will be very useful.

buildout-versions is a replacement for buildout.dumppickedversions, and
shouldn't have this issue.

Marius Gedminas
-- 
If you are angry with someone, you should walk a mile in their shoes... then
you'll be a mile away from them, and you'll have their shoes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110114/e08f0614/attachment.pgp>

From liujisi at google.com  Wed Jan 12 09:42:34 2011
From: liujisi at google.com (Pherl Liu)
Date: Wed, 12 Jan 2011 16:42:34 +0800
Subject: [Distutils] Bootstrap use_setuptools() in ez_setup.py failure
Message-ID: <AANLkTi=NcqsWWvP-SAhTcKnVafakwJFZKifLs+rDoH=0@mail.gmail.com>

Hi,

I got some error messages when using ez_setup to download and use the
easy_install.

# setup.py
from ez_setup import use_setuptools
use_setuptools()

from setuptools import setup

setup(name = "blabla",
      test_suite = "some_test",
      namespace_package = ["some_namespace"],
            # many other options
)

It can download the setuptools-0.6c9-py2.6.egg file correctly, but when I
run "python setup.py test" it complains:

/usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution
option: 'namespace_packages'
  warnings.warn(msg)
/usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution
option: 'test_suite'
  warnings.warn(msg)
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'test'

It seems the easy_install egg isn't used, and the "setup" is just from the
built-in distutil.
I did several things:
1) update the ez_setup.py but the only difference is it downloads the c11
egg, which doesn't work either.
2) unzip the egg to the current directory. "python setup.py test" passed...
3) install the easy_install. "python setup.py test" passed...
4) unzip the egg to the current directory, remove other files but only
reserve pkg_resources.py and the egg. "python setup.py test" passed..

So I guess there might be some import problem in my machine (ubuntu lucid)
that the pkg_resources.py cannot be loaded from the egg?

Thanks,
Pherl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110112/dc99d179/attachment.html>

From pje at telecommunity.com  Fri Jan 14 15:45:11 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 14 Jan 2011 09:45:11 -0500
Subject: [Distutils] Bootstrap use_setuptools() in ez_setup.py  failure
In-Reply-To: <AANLkTi=NcqsWWvP-SAhTcKnVafakwJFZKifLs+rDoH=0@mail.gmail.c
 om>
References: <AANLkTi=NcqsWWvP-SAhTcKnVafakwJFZKifLs+rDoH=0@mail.gmail.com>
Message-ID: <20110114144525.BADBF3A40F5@sparrow.telecommunity.com>

At 04:42 PM 1/12/2011 +0800, Pherl Liu wrote:
>Hi,
>
>I got some error messages when using ez_setup to download and use 
>the easy_install.
>
># setup.py
>from ez_setup import use_setuptools
>use_setuptools()
>
>from setuptools import setup
>
>setup(name = "blabla",
>       test_suite = "some_test",
>       namespace_package = ["some_namespace"],
>             # many other options
>)
>
>
>So I guess there might be some import problem in my machine (ubuntu 
>lucid) that the pkg_resources.py cannot be loaded from the egg?

Try running this script in your project directory:

    from ez_setup import use_setuptools
    use_setuptools()

    import sys, setuptools, pkg_resources
    print sys.path
    print pkg_resources.__file__
    print setuptools.__file__

This should tell us what's going on with your "import problem" more 
specifically.  ;-) 


From chris at simplistix.co.uk  Fri Jan 14 16:07:47 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 14 Jan 2011 15:07:47 +0000
Subject: [Distutils] buildout pinning versions and egg requires
In-Reply-To: <AANLkTi=1GEz372fnNwQL=tm4c=ungoK8jCpJ2Kpmqv=1@mail.gmail.com>
References: <AANLkTikkEN63L8_-nEpVihRvQNw5HnHu7E=nJrE6Cfn_@mail.gmail.com>	<igle17$sbv$1@dough.gmane.org>
	<AANLkTi=1GEz372fnNwQL=tm4c=ungoK8jCpJ2Kpmqv=1@mail.gmail.com>
Message-ID: <4D3066C3.6020801@simplistix.co.uk>

On 13/01/2011 14:27, Benji York wrote:
> On Wed, Jan 12, 2011 at 6:38 PM, Maurits van Rees
> <m.van.rees at zestsoftware.nl>  wrote:
>> Op 12-01-11 23:33, Jeff Kunce schreef:
>>>
>>> I'm having trouble pinning versions in my buildout.  It looks like
>>> "requires.txt" for the recipe eggs are overriding what I specify in
>>> versions.cfg.
>>
>> Looks like you have a typo in the version pin: it should be Zope2 with a
>> capital 'Z'.
>
> Adding allow-picked-versions = false to your [buildout] section can help
> keep this from happening.

Yeah, but that only tells you one problem for each run, which is kinda 
annoying ;-)

...which is one of the reasons I wrote buildout-versions!

cheers,

Chris

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

From chris at simplistix.co.uk  Fri Jan 14 16:10:56 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 14 Jan 2011 15:10:56 +0000
Subject: [Distutils] buildout pinning versions and egg requires
In-Reply-To: <AANLkTinhSuuvFhFRXmAhViawzjTtcFYhi33BcBPjRS9X@mail.gmail.com>
References: <AANLkTikkEN63L8_-nEpVihRvQNw5HnHu7E=nJrE6Cfn_@mail.gmail.com>	<igle17$sbv$1@dough.gmane.org>
	<AANLkTinhSuuvFhFRXmAhViawzjTtcFYhi33BcBPjRS9X@mail.gmail.com>
Message-ID: <4D306780.4070406@simplistix.co.uk>

On 13/01/2011 16:00, Jeff Kunce wrote:
> That explains a lot.  We are running on windows, and our versions.cfg
> was generated by buildout.dumppickedversions - it looks like everything
> in that file is all lower case.  Your suggestions will be very useful.

Heh, yes, this was an even more specific reason why I forked 
buildout-versions from buildout.dumppickedversions ;-)

Chris

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

From benji at benjiyork.com  Fri Jan 14 16:17:00 2011
From: benji at benjiyork.com (Benji York)
Date: Fri, 14 Jan 2011 10:17:00 -0500
Subject: [Distutils] buildout pinning versions and egg requires
In-Reply-To: <4D3066C3.6020801@simplistix.co.uk>
References: <AANLkTikkEN63L8_-nEpVihRvQNw5HnHu7E=nJrE6Cfn_@mail.gmail.com>
	<igle17$sbv$1@dough.gmane.org>
	<AANLkTi=1GEz372fnNwQL=tm4c=ungoK8jCpJ2Kpmqv=1@mail.gmail.com>
	<4D3066C3.6020801@simplistix.co.uk>
Message-ID: <AANLkTinVsSg67euVKDDhQmxGnMOQpJm1oZ6+SYxrT7fK@mail.gmail.com>

On Fri, Jan 14, 2011 at 10:07 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> On 13/01/2011 14:27, Benji York wrote:
>>
>> On Wed, Jan 12, 2011 at 6:38 PM, Maurits van Rees
>> <m.van.rees at zestsoftware.nl> ?wrote:
>>>
>>> Op 12-01-11 23:33, Jeff Kunce schreef:
>>>>
>>>> I'm having trouble pinning versions in my buildout. ?It looks like
>>>> "requires.txt" for the recipe eggs are overriding what I specify in
>>>> versions.cfg.
>>>
>>> Looks like you have a typo in the version pin: it should be Zope2 with a
>>> capital 'Z'.
>>
>> Adding allow-picked-versions = false to your [buildout] section can help
>> keep this from happening.
>
> Yeah, but that only tells you one problem for each run, which is kinda
> annoying ;-)

When used to find unspecified versions it is indeed annoying (and I'm
sure buildout-versions is good at that).

But that's not what I was suggesting.  I was suggesting
allow-picked-versions be used to ensure that there are no dependencies
without specified versions.
-- 
Benji York

From rafael at nexedi.com  Fri Jan 14 22:27:02 2011
From: rafael at nexedi.com (Rafael Monnerat)
Date: Fri, 14 Jan 2011 19:27:02 -0200
Subject: [Distutils] buildout download cache
In-Reply-To: <pan.2011.01.11.08.03.35.802885@ID-174572.user.uni-berlin.de>
References: <20110109225918.143957xkisc2hghi@mail.tiolive.com>
	<pan.2011.01.11.08.03.35.802885@ID-174572.user.uni-berlin.de>
Message-ID: <4D30BFA6.4090502@nexedi.com>


Hi,

I made a patch to zc.buildout.download which introduces a very simple 
"network cache" or "cache into network".  So, I tried to keep this as 
simple and generic as buildout is. Basically, with the patch the 
download of a file, follow this order:

1. Try Local Cache (no change from original)
2. Try network cache (I explain bellow)
3. Try original URL
4. Post file data to network cache (pure HTTP)

So, the network cache is just one URL where files are placed (can be any 
simple HTTP) and identified by file MD5 like this:

  GET http://my.company.shared.cache/md5_provided_for_the_file

The cache update is done by a simple post to same adress:

  POST http://my.company.shared.cache/md5_provided_for_the_file < data

As I'm familiar with ERP5, I implemented a very simple way to handle 
this cache, but I can also contribute with a simpler solution like 
eggproxy do for eggs. If you think my patch is useful and ok.

As I don't have access to svn to make a branch, I'm attaching the patch.

With network cache, I think people can share downloads into private 
networks or prevent your build is break when some source is unavailable.

If you consider this behaviour inapropriate for the core of buildout, 
but appropriated to be an buildout extension, let me know.

Regards,
Rafael Monnerat

On 11-01-2011 06:03, Thomas Lotze wrote:
> rafael wrote:
>
>> We are planning to extend buildout download API to provide a distributed
>> automatic
>> packaging and caching system so that even if original source web site is
>> down, the buildout process can stil run. This could also be useful to
>> build software in
>> secured networks.
> I'd strongly suggest keeping this logic out of the download API. It sounds
> like something that may potentially grow a lot more complex than a simple
> "download this URL, with or without using a cache" gesture.
>
> In my opinion, a distributed packaging system is application logic from
> the perspective of a generic framework such as zc.buildout. It might be
> implemented by a recipe, some library on top of the download API or some
> other mechanism altogether, but it should neither complicate the semantics
> of the existing download API nor add a new one to the zc.buildout code
> base.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: zc.buildout.download.patch
Type: text/x-diff
Size: 3063 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110114/f1121c86/attachment.patch>

From mailing at franzoni.eu  Sun Jan 16 14:32:54 2011
From: mailing at franzoni.eu (Alan Franzoni)
Date: Sun, 16 Jan 2011 14:32:54 +0100
Subject: [Distutils] Setting version from commandline or setup.cfg?
In-Reply-To: <ighmln$m1p$1@dough.gmane.org>
References: <AANLkTimqEEbgPf-xN1zYK1gUtFqpQqMnzXYyPW-mxXcD@mail.gmail.com>
	<ighmln$m1p$1@dough.gmane.org>
Message-ID: <AANLkTi=iEpiLs8U_y81hCduUDicgGz2vRbMsonzPdDWN@mail.gmail.com>

On Tue, Jan 11, 2011 at 2:41 PM, Maurits van Rees
<m.van.rees at zestsoftware.nl> wrote:
> Op 11-01-11 12:51, Alan Franzoni schreef:
>>
>> Hello,
>> I'm trying to automate my release process from vcs - something like:
>>
>> run tests ->
>> ?fetch current major, minor from branch (e.g. release_1.2) and
>> revision from tag (e.g. v1.2.1) ->
>> upload with current major, minor and ?revision +1>
>> tag with such current major, minor and incremented revision.
>>
>>
>> I'd like to set my version from outside my setup.py file, either via
>> setup.py or a commandline option - I don't want to execute code in my
>> setup.py since this usually causes all sort of headaches with missing
>> dependencies.
>>
>> Is there any proper way to do it? Might I break ?other things
>> unexpectedly?
>
> I suggest using a tool like:
> http://pypi.python.org/pypi/zest.releaser

I have played a bit with zest.releaser, and while it seems interesting
I'm not sure about some things, e.g.:

I'd like to test my project *before* committing any version change or
tagging anything. I'd like to pass a "candidate changeset" for a
release; if all tests on such release succeed, I'd then like to tag
the current changeset, upload everything to pypi, upgrade setup.py (or
version.txt) with the next development version. zest.releaser offers
setup.py entrypoint hooks, but maybe a buildout hook (run another
part) would work better?

Also, version.txt looks better than embedding the version in setup.py,
but I'd like to follow even more a convention-over-configuration
thing; I'd like release branches to be named something like

release_1.2
release_1.3

and I'd really like to pull version numbers from the branch name and
latest revision from the tag info - nor version.txt neither setup.py
should be committed at any time - that's often an issue because when
working with multiple branches, the forward merge of version changes
often produces merge errors that must be corrected manually. Saving
version info in metadata like branch names or tags is a better
solution, I think.

I'll try playing a bit with the zest.releaser source by the way, If I
can reach a good result I'll let you know.


-- 
Alan Franzoni
--
contact me at public@[mysurname].eu

From m.van.rees at zestsoftware.nl  Sun Jan 16 20:50:41 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Sun, 16 Jan 2011 20:50:41 +0100
Subject: [Distutils] Setting version from commandline or setup.cfg?
In-Reply-To: <AANLkTi=iEpiLs8U_y81hCduUDicgGz2vRbMsonzPdDWN@mail.gmail.com>
References: <AANLkTimqEEbgPf-xN1zYK1gUtFqpQqMnzXYyPW-mxXcD@mail.gmail.com>	<ighmln$m1p$1@dough.gmane.org>
	<AANLkTi=iEpiLs8U_y81hCduUDicgGz2vRbMsonzPdDWN@mail.gmail.com>
Message-ID: <igvi6h$ulb$1@dough.gmane.org>

Op 16-01-11 14:32, Alan Franzoni schreef:
> I have played a bit with zest.releaser, and while it seems interesting
> I'm not sure about some things, e.g.:
>
> I'd like to test my project *before* committing any version change or
> tagging anything. I'd like to pass a "candidate changeset" for a
> release; if all tests on such release succeed, I'd then like to tag
> the current changeset, upload everything to pypi, upgrade setup.py (or
> version.txt) with the next development version. zest.releaser offers
> setup.py entrypoint hooks, but maybe a buildout hook (run another
> part) would work better?

I would say just run the tests manually first (possibly as simple as 
running bin/test if you have a good buildout configuration) and then use 
the fullrelease command from zest.releaser.

If you are afraid that changing the version string and updating the 
changelog/history file might possibly break the tests you could first 
run the prerelease command to set the version and history, then run the 
tests, then run the release command to tag and push to pypi or somewhere 
else, then the postrelease command to update the version and changelog 
of your current branch/trunk checkout to a development version.

>
> Also, version.txt looks better than embedding the version in setup.py,

For the record, having a version.txt is a convention from years ago when 
Zope/Plone products needed it, because python packages with a setup.py 
were not widely used within Zope at that time, possibly because they had 
not been invented yet. :-)

> but I'd like to follow even more a convention-over-configuration
> thing; I'd like release branches to be named something like
>
> release_1.2
> release_1.3
>
> and I'd really like to pull version numbers from the branch name and
> latest revision from the tag info - nor version.txt neither setup.py
> should be committed at any time - that's often an issue because when
> working with multiple branches, the forward merge of version changes
> often produces merge errors that must be corrected manually. Saving
> version info in metadata like branch names or tags is a better
> solution, I think.

When you upload your package to pypi.python.org setup.py needs to know 
what version it is.  In other words: you need some way of having 'python 
setup.py --version' come up with the correct version.

Yes, merging can produce conflicts, but if version conflicts in a 
changelog and a setup.py are your worst merge problems then you can 
count yourself blessed. :-)

> I'll try playing a bit with the zest.releaser source by the way, If I
> can reach a good result I'll let you know.

Cool.  I get the feeling you are trying to solve a problem that I don't 
have or that I do not consider a problem though, so don't get your hopes 
up too high that changes are accepted for a release.

But the code is in the Plone collective, so feel free to make a branch 
there:
https://svn.plone.org/svn/collective/zest.releaser/trunk

Getting write access to the Plone collective should not be too 
difficult.  Short instructions are here:
http://dev.plone.org/collective

Cheers,

-- 
Maurits van Rees
Programmer at Zest Software http://zestsoftware.nl
Personal website http://maurits.vanrees.org/


From mailing at franzoni.eu  Sun Jan 16 23:08:08 2011
From: mailing at franzoni.eu (Alan Franzoni)
Date: Sun, 16 Jan 2011 23:08:08 +0100
Subject: [Distutils] Setting version from commandline or setup.cfg?
In-Reply-To: <igvi6h$ulb$1@dough.gmane.org>
References: <AANLkTimqEEbgPf-xN1zYK1gUtFqpQqMnzXYyPW-mxXcD@mail.gmail.com>
	<ighmln$m1p$1@dough.gmane.org>
	<AANLkTi=iEpiLs8U_y81hCduUDicgGz2vRbMsonzPdDWN@mail.gmail.com>
	<igvi6h$ulb$1@dough.gmane.org>
Message-ID: <AANLkTi=CSo8a56FZJues9guPzYuASv0tr64To2b2iZsh@mail.gmail.com>

On Sun, Jan 16, 2011 at 8:50 PM, Maurits van Rees
<m.van.rees at zestsoftware.nl> wrote:
> I would say just run the tests manually first (possibly as simple as running
> bin/test if you have a good buildout configuration) and then use the
> fullrelease command from zest.releaser.

Yup, I'm tinkering with something like that, and it seems fine in
fact. I don't know why I thought it was harder.

>> and I'd really like to pull version numbers from the branch name and
>> latest revision from the tag info - nor version.txt neither setup.py
>> should be committed at any time - that's often an issue because when
>> working with multiple branches, the forward merge of version changes
>> often produces merge errors that must be corrected manually. Saving
>> version info in metadata like branch names or tags is a better
>> solution, I think.
>
> When you upload your package to pypi.python.org setup.py needs to know what
> version it is. ?In other words: you need some way of having 'python setup.py
> --version' come up with the correct version.

I have noticed that, and it ultimately makes sense. Once it's a
.tar.gz there's no VCS under it, it can't possibly know which version
is around.

> Yes, merging can produce conflicts, but if version conflicts in a changelog
> and a setup.py are your worst merge problems then you can count yourself
> blessed. :-)

Wherever there's unneeded manual work, there's something to fix.

Such problems does not arise in Python projects, it's often very
painful when developing Java with Maven as well; and can sometimes
have hellish consequences. If after a long-and-painful merge anyone
forgets to put the correct version number in the version file and then
goes on by releasing it, stakes are high that problems will arise.

> Cool. ?I get the feeling you are trying to solve a problem that I don't have
> or that I do not consider a problem though, so don't get your hopes up too
> high that changes are accepted for a release.

That's probable. In that case I won't modify the releaser, maybe I
could start a totally different project, but I'd like to reuse what
can be reused.

-- 
Alan Franzoni
--
contact me at public@[mysurname].eu

From alexis at notmyidea.org  Mon Jan 17 02:13:37 2011
From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=)
Date: Mon, 17 Jan 2011 02:13:37 +0100
Subject: [Distutils] PEP 345: real-world examples of "virtual" projects
 (Provides-Release)
In-Reply-To: <AANLkTikq1HfoYpQ95zZrhqY+9aY9XinJvXD5dDy8wAFP@mail.gmail.com>
References: <4D111F23.2040404@activestate.com>	<4D147F6D.2040605@notmyidea.org>	<4D2792E0.1000101@activestate.com>
	<AANLkTikq1HfoYpQ95zZrhqY+9aY9XinJvXD5dDy8wAFP@mail.gmail.com>
Message-ID: <4D3397C1.7010606@notmyidea.org>

Hi, sorry for the delay, I know how this can be irritating sometimes.

Le 07/01/2011 23:48, Sridhar a ?crit :
> What is the benefit of distributing two projects in a single
> distribution, compared to the more simpler (traditional) solution of
> distributing them in separate distributions  (and, optionally, making
> one depend on another; eg: 'core' depend on 'defaultplugins')? Does
> this benefit justify the cost of introducing a new metadata field?

I prefer to distribute things in separated distributions, but it's
sometimes simpler to not do that, from the packager POV (because it's
only one project to maintain instead of many).

I can't say if it's something we really need or not. Maybe the question
is to ask to the ones who have introduced and thought about it first
(tarek maybe? I'm not sure)

>> setuptools and distribute can be both provided by the same virtual project.
> 
> Is this the only real-world use of virtual projects? Are there
> (potential) others?

We can have a (fixed) API to deal with something (a database, a parser,
etc.), but the internal working is up to the implementation. This means
that even the results can be different, but the calls, the API remains
the same.

One exemple I have in mind is the parsing of .ini files. A virtual
project can be "ini-parser", and two implmentations can be a simple ini
parser, and a ini parser which supports nested categories.

Then, a distributio can depend either on a specific parser, or on the
virtual project, depending the needs. If one of those parsers is
installed, and a distribution do have a dependency to the virtual dist,
then there will be no need to install a specific dist.

Maybe can I polish this example and replace the one from the PEP ?

Hope this useful,
Alex.

From liujisi at google.com  Wed Jan 19 07:43:07 2011
From: liujisi at google.com (Pherl Liu)
Date: Wed, 19 Jan 2011 14:43:07 +0800
Subject: [Distutils] Bootstrap use_setuptools() in ez_setup.py failure
In-Reply-To: <20110114144525.BADBF3A40F5@sparrow.telecommunity.com>
References: <AANLkTi=NcqsWWvP-SAhTcKnVafakwJFZKifLs+rDoH=0@mail.gmail.com>
	<20110114144525.BADBF3A40F5@sparrow.telecommunity.com>
Message-ID: <AANLkTikL247MCuytwvFG4BkK+kF1zSJZAd6baLCsTXiJ@mail.gmail.com>

print sys.path shows the egg is the first item.
['setuptools-0.6c9-py2.6.egg', '', '/usr/lib/python2.6',
'/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk',
'/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload',
'/usr/lib/python2.6/dist-packages', ....]


print pkg_resources.__file__ shows
/usr/lib/python2.6/dist-packages/pkg_resources.pyc

print setuptools.__file__ shows
setuptools-0.6c9-py2.6.egg/setuptools/__init__.py

Hmm, then it's strange.. Kenton (cc-ed) also got the same problem when
running this on Ubuntu + python 2.6.
The pkg_resources is from /usr/lib/python2.6/dist-packages/, while the egg
should have a higher import priority than /usr/lib/python2.6/dist-packages
in sys.path...

On Fri, Jan 14, 2011 at 10:45 PM, P.J. Eby <pje at telecommunity.com> wrote:

> At 04:42 PM 1/12/2011 +0800, Pherl Liu wrote:
>
>> Hi,
>>
>> I got some error messages when using ez_setup to download and use the
>> easy_install.
>>
>> # setup.py
>> from ez_setup import use_setuptools
>> use_setuptools()
>>
>> from setuptools import setup
>>
>> setup(name = "blabla",
>>      test_suite = "some_test",
>>      namespace_package = ["some_namespace"],
>>            # many other options
>> )
>>
>>
>> So I guess there might be some import problem in my machine (ubuntu lucid)
>> that the pkg_resources.py cannot be loaded from the egg?
>>
>
> Try running this script in your project directory:
>
>
>   from ez_setup import use_setuptools
>   use_setuptools()
>
>   import sys, setuptools, pkg_resources
>   print sys.path
>   print pkg_resources.__file__
>   print setuptools.__file__
>
> This should tell us what's going on with your "import problem" more
> specifically.  ;-)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110119/5bca9486/attachment.html>

From liujisi at google.com  Wed Jan 19 08:40:39 2011
From: liujisi at google.com (Pherl Liu)
Date: Wed, 19 Jan 2011 15:40:39 +0800
Subject: [Distutils] Bootstrap use_setuptools() in ez_setup.py failure
In-Reply-To: <AANLkTikL247MCuytwvFG4BkK+kF1zSJZAd6baLCsTXiJ@mail.gmail.com>
References: <AANLkTi=NcqsWWvP-SAhTcKnVafakwJFZKifLs+rDoH=0@mail.gmail.com>
	<20110114144525.BADBF3A40F5@sparrow.telecommunity.com>
	<AANLkTikL247MCuytwvFG4BkK+kF1zSJZAd6baLCsTXiJ@mail.gmail.com>
Message-ID: <AANLkTimWcuQvhqwgfyHQj_5kMRA0R3iUghG6RbN+sZZN@mail.gmail.com>

Well..

I think I can fix this by editing ez_setup.py

adding oneline after pkg_resources.DistributionNotFound is caught, in
use_setuptools()

del pkg_resources, sys.modules['pkg_resources']

Not sure if this makes sense.

A patch based on 0.6c9.

diff --git a/python/ez_setup.py b/python/ez_setup.py
index b7a9849..cef3557 100755
--- a/python/ez_setup.py
+++ b/python/ez_setup.py
@@ -113,6 +113,7 @@ def use_setuptools(
             del pkg_resources, sys.modules['pkg_resources']    # reload ok
             return do_download()
     except pkg_resources.DistributionNotFound:
+        del pkg_resources, sys.modules['pkg_resources']    # reload ok
         return do_download()






On Wed, Jan 19, 2011 at 2:43 PM, Pherl Liu <liujisi at google.com> wrote:

> print sys.path shows the egg is the first item.
> ['setuptools-0.6c9-py2.6.egg', '', '/usr/lib/python2.6',
> '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk',
> '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload',
> '/usr/lib/python2.6/dist-packages', ....]
>
>
> print pkg_resources.__file__ shows
> /usr/lib/python2.6/dist-packages/pkg_resources.pyc
>
> print setuptools.__file__ shows
> setuptools-0.6c9-py2.6.egg/setuptools/__init__.py
>
> Hmm, then it's strange.. Kenton (cc-ed) also got the same problem when
> running this on Ubuntu + python 2.6.
> The pkg_resources is from /usr/lib/python2.6/dist-packages/, while the egg
> should have a higher import priority than /usr/lib/python2.6/dist-packages
> in sys.path...
>
>
> On Fri, Jan 14, 2011 at 10:45 PM, P.J. Eby <pje at telecommunity.com> wrote:
>
>> At 04:42 PM 1/12/2011 +0800, Pherl Liu wrote:
>>
>>> Hi,
>>>
>>> I got some error messages when using ez_setup to download and use the
>>> easy_install.
>>>
>>> # setup.py
>>> from ez_setup import use_setuptools
>>> use_setuptools()
>>>
>>> from setuptools import setup
>>>
>>> setup(name = "blabla",
>>>      test_suite = "some_test",
>>>      namespace_package = ["some_namespace"],
>>>            # many other options
>>> )
>>>
>>>
>>> So I guess there might be some import problem in my machine (ubuntu
>>> lucid) that the pkg_resources.py cannot be loaded from the egg?
>>>
>>
>> Try running this script in your project directory:
>>
>>
>>   from ez_setup import use_setuptools
>>   use_setuptools()
>>
>>   import sys, setuptools, pkg_resources
>>   print sys.path
>>   print pkg_resources.__file__
>>   print setuptools.__file__
>>
>> This should tell us what's going on with your "import problem" more
>> specifically.  ;-)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110119/eeccdbc1/attachment.html>

From pje at telecommunity.com  Wed Jan 19 17:53:18 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Wed, 19 Jan 2011 11:53:18 -0500
Subject: [Distutils] Bootstrap use_setuptools() in ez_setup.py  failure
In-Reply-To: <AANLkTimWcuQvhqwgfyHQj_5kMRA0R3iUghG6RbN+sZZN@mail.gmail.c
 om>
References: <AANLkTi=NcqsWWvP-SAhTcKnVafakwJFZKifLs+rDoH=0@mail.gmail.com>
	<20110114144525.BADBF3A40F5@sparrow.telecommunity.com>
	<AANLkTikL247MCuytwvFG4BkK+kF1zSJZAd6baLCsTXiJ@mail.gmail.com>
	<AANLkTimWcuQvhqwgfyHQj_5kMRA0R3iUghG6RbN+sZZN@mail.gmail.com>
Message-ID: <20110119165325.517CC3A4175@sparrow.telecommunity.com>

At 03:40 PM 1/19/2011 +0800, Pherl Liu wrote:
>Well..
>
>I think I can fix this by editing ez_setup.py
>
>adding oneline after pkg_resources.DistributionNotFound is caught, 
>in use_setuptools()
>
>del pkg_resources, sys.modules['pkg_resources']
>
>Not sure if this makes sense.

That's already in current versions of ez_setup.py; 0.6c9 is several 
years old.  I'd suggest you use the svn externals to keep it up-to-date.  See:

   http://peak.telecommunity.com/DevCenter/setuptools#managing-multiple-projects

for details.



From liujisi at google.com  Thu Jan 20 06:55:07 2011
From: liujisi at google.com (Pherl Liu)
Date: Thu, 20 Jan 2011 13:55:07 +0800
Subject: [Distutils] Bootstrap use_setuptools() in ez_setup.py failure
In-Reply-To: <20110119165325.517CC3A4175@sparrow.telecommunity.com>
References: <AANLkTi=NcqsWWvP-SAhTcKnVafakwJFZKifLs+rDoH=0@mail.gmail.com>
	<20110114144525.BADBF3A40F5@sparrow.telecommunity.com>
	<AANLkTikL247MCuytwvFG4BkK+kF1zSJZAd6baLCsTXiJ@mail.gmail.com>
	<AANLkTimWcuQvhqwgfyHQj_5kMRA0R3iUghG6RbN+sZZN@mail.gmail.com>
	<20110119165325.517CC3A4175@sparrow.telecommunity.com>
Message-ID: <AANLkTinEhhnqkFrRhHbmcDgBZbOVuSsMyTYoKYoctYAd@mail.gmail.com>

Hmm, I think it now only delete pkg_resource when
pkg_resrouces.VersionConflict is caught, but the fix should be also delete
pkg_resources when pkg_resources.DistributionNotFound is caught. The code
looks like:

   try:
        pkg_resources.require("setuptools>="+version); return
    except pkg_resources.VersionConflict, e:
        if was_imported:
            print >>sys.stderr, (
            "The required version of setuptools (>=%s) is not available,
and\n"
            "can't be installed while this script is running. Please
install\n"
            " a more recent version first, using 'easy_install -U
setuptools'."
            "\n\n(Currently using %r)"
            ) % (version, e.args[0])
            sys.exit(2)
        else:
            del pkg_resources, sys.modules['pkg_resources']    # reload ok
            return do_download()
    except pkg_resources.DistributionNotFound:
        *del pkg_resources, sys.modules['pkg_resources']*  #  added this
line.
        return do_download()


On Thu, Jan 20, 2011 at 12:53 AM, P.J. Eby <pje at telecommunity.com> wrote:

> At 03:40 PM 1/19/2011 +0800, Pherl Liu wrote:
>
>> Well..
>>
>> I think I can fix this by editing ez_setup.py
>>
>> adding oneline after pkg_resources.DistributionNotFound is caught, in
>> use_setuptools()
>>
>> del pkg_resources, sys.modules['pkg_resources']
>>
>> Not sure if this makes sense.
>>
>
> That's already in current versions of ez_setup.py; 0.6c9 is several years
> old.  I'd suggest you use the svn externals to keep it up-to-date.  See:
>
>
> http://peak.telecommunity.com/DevCenter/setuptools#managing-multiple-projects
>
> for details.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110120/faabd3f9/attachment.html>

From pje at telecommunity.com  Thu Jan 20 19:58:17 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 20 Jan 2011 13:58:17 -0500
Subject: [Distutils] Bootstrap use_setuptools() in ez_setup.py  failure
In-Reply-To: <AANLkTinEhhnqkFrRhHbmcDgBZbOVuSsMyTYoKYoctYAd@mail.gmail.c
 om>
References: <AANLkTi=NcqsWWvP-SAhTcKnVafakwJFZKifLs+rDoH=0@mail.gmail.com>
	<20110114144525.BADBF3A40F5@sparrow.telecommunity.com>
	<AANLkTikL247MCuytwvFG4BkK+kF1zSJZAd6baLCsTXiJ@mail.gmail.com>
	<AANLkTimWcuQvhqwgfyHQj_5kMRA0R3iUghG6RbN+sZZN@mail.gmail.com>
	<20110119165325.517CC3A4175@sparrow.telecommunity.com>
	<AANLkTinEhhnqkFrRhHbmcDgBZbOVuSsMyTYoKYoctYAd@mail.gmail.com>
Message-ID: <20110120185828.BCB4F3A4065@sparrow.telecommunity.com>

At 01:55 PM 1/20/2011 +0800, Pherl Liu wrote:
>Hmm, I think it now only delete pkg_resource when 
>pkg_resrouces.VersionConflict is caught, but the fix should be also 
>delete pkg_resources when pkg_resources.DistributionNotFound is caught.

Good catch.  Under previous use cases, the only time you'd have 
pkg_resources and *not* setuptools, it would be if you were bundling 
pkg_resources.  Nowadays, though, some distros split setuptools from 
pkg_resources, so you can have an older, distro-supplied 
pkg_resources, but no setuptools.

Anyway, I've fixed this in SVN and on the website now.  Thanks!


From janwijbrand at gmail.com  Thu Jan 20 21:16:22 2011
From: janwijbrand at gmail.com (Jan-Wijbrand Kolman)
Date: Thu, 20 Jan 2011 21:16:22 +0100
Subject: [Distutils] current ez_setup.py appears to refers a non existing
	URL?
Message-ID: <iha56m$157$1@dough.gmane.org>

Hi,

Since about an hour or so, when I run ez_setup.py (by way of a 
zc.buildout bootstrap.py script), I get this:

Downloading 
http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c12-py2.7.egg
Traceback (most recent call last):
   File "bootstrap.py", line 172, in <module>
     ez['use_setuptools'](**setup_args)
   File "<string>", line 76, in use_setuptools
   File "<string>", line 70, in do_download
   File "<string>", line 131, in download_setuptools
   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 126, in 
urlopen
     return _opener.open(url, data, timeout)
   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 398, in open
     response = meth(req, response)
   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 511, in 
http_response
     'http', request, response, code, msg, hdrs)
   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 436, in error
     return self._call_chain(*args)
   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 370, in 
_call_chain
     result = func(*args)
   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 519, in 
http_error_default
     raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 404: Not Found

And indeed, when I download ez_setup.py myself:

$ wget http://peak.telecommunity.com/dist/ez_setup.py

and run it, I also get the 404 on the URL:

 
http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c12-py2.7.egg.

I have been bootstrap.py-ing packages all day long and suddenly they 
stopped to work. Am I doing something wrong, or is the ez_setup.py broken?

Kind regards, jw



From rafael at nexedi.com  Thu Jan 20 21:47:47 2011
From: rafael at nexedi.com (Rafael Monnerat)
Date: Thu, 20 Jan 2011 18:47:47 -0200
Subject: [Distutils] current ez_setup.py appears to refers a non
 existing URL?
In-Reply-To: <iha56m$157$1@dough.gmane.org>
References: <iha56m$157$1@dough.gmane.org>
Message-ID: <4D389F73.9080801@nexedi.com>


Hi,

I'm getting same problem for 2.6 when I use bootstrap.py .

Regards,
Rafael Monnerat

On 20-01-2011 18:16, Jan-Wijbrand Kolman wrote:
> Hi,
>
> Since about an hour or so, when I run ez_setup.py (by way of a 
> zc.buildout bootstrap.py script), I get this:
>
> Downloading 
> http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c12-py2.7.egg
> Traceback (most recent call last):
>   File "bootstrap.py", line 172, in <module>
>     ez['use_setuptools'](**setup_args)
>   File "<string>", line 76, in use_setuptools
>   File "<string>", line 70, in do_download
>   File "<string>", line 131, in download_setuptools
>   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 126, in 
> urlopen
>     return _opener.open(url, data, timeout)
>   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 398, in open
>     response = meth(req, response)
>   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 511, in 
> http_response
>     'http', request, response, code, msg, hdrs)
>   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 436, in 
> error
>     return self._call_chain(*args)
>   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 370, in 
> _call_chain
>     result = func(*args)
>   File "/home/jw/runtime/2.7/lib/python2.7/urllib2.py", line 519, in 
> http_error_default
>     raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
> urllib2.HTTPError: HTTP Error 404: Not Found
>
> And indeed, when I download ez_setup.py myself:
>
> $ wget http://peak.telecommunity.com/dist/ez_setup.py
>
> and run it, I also get the 404 on the URL:
>
>
> http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c12-py2.7.egg. 
>
>
> I have been bootstrap.py-ing packages all day long and suddenly they 
> stopped to work. Am I doing something wrong, or is the ez_setup.py 
> broken?
>
> Kind regards, jw
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


From setuptools at bugs.python.org  Fri Jan 21 01:37:30 2011
From: setuptools at bugs.python.org (Guy Rozendorn)
Date: Fri, 21 Jan 2011 00:37:30 +0000
Subject: [Distutils] [issue120] cli.exe quits on ctrl-c, but python doesn't
In-Reply-To: <1295570250.3.0.250316976145.issue120@psf.upfronthosting.co.za>
Message-ID: <1295570250.3.0.250316976145.issue120@psf.upfronthosting.co.za>


New submission from Guy Rozendorn <guy at rzn.co.il>:

the cli should use SetConsoleCtrlHandler to ignore CTRL-C and pass it to its child process

----------
messages: 573
nosy: guyroz
priority: bug
status: unread
title: cli.exe quits on ctrl-c, but python doesn't

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

From pje at telecommunity.com  Fri Jan 21 04:04:36 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Thu, 20 Jan 2011 22:04:36 -0500
Subject: [Distutils] current ez_setup.py appears to refers a non
 existing URL?
In-Reply-To: <iha56m$157$1@dough.gmane.org>
References: <iha56m$157$1@dough.gmane.org>
Message-ID: <20110121030447.E62593A4065@sparrow.telecommunity.com>

At 09:16 PM 1/20/2011 +0100, Jan-Wijbrand Kolman wrote:
>And indeed, when I download ez_setup.py myself:
>
>$ wget http://peak.telecommunity.com/dist/ez_setup.py
>
>and run it, I also get the 404 on the URL:

When I made the changes earlier today, I accidentally pushed the 
0.6c12 development version to /dist instead of the stable 0.6c12 
version.  It's fixed now; sorry about that.


From dave at krondo.com  Mon Jan 24 22:02:10 2011
From: dave at krondo.com (Dave Peticolas)
Date: Mon, 24 Jan 2011 13:02:10 -0800
Subject: [Distutils] zc.buildout socket-timeout option
Message-ID: <AANLkTi=eA-Kj=dhkFUYytaHKNYV6UhAMCunqWzFj+00X@mail.gmail.com>

A quick question about this buildout option.

Am I right that it isn't actually enabled yet?

It doesn't seem to have any effect for me (this is on buildout 1.5.2),
but using -t has a noticeable effect.

thanks,
dave

From amcnabb at mcnabbs.org  Tue Jan 25 20:03:13 2011
From: amcnabb at mcnabbs.org (Andrew McNabb)
Date: Tue, 25 Jan 2011 12:03:13 -0700
Subject: [Distutils] setuptools and man pages
Message-ID: <20110125190313.GD26225@mcnabbs.org>

I am maintaining a package that includes several scripts, and I recently
added a man page.  Unfortunately, I was unable to figure out how to
specify the man page with setuptools.  I ended up switching back to
vanilla distutils, which allowed me to specify the man page in setup.py:

    data_files=[('man/man1', ['man/man1/pssh.1'])]

Is there an equivalent way to do this with setuptools?  The closest
thing I could find in the setuptools documentation was, "Note, by the
way, that this encapsulation of data files means that you can't actually
install data files to some arbitrary location on a user's machine; this
is a feature, not a bug."  I appreciate the well-intended thought, but I
can't find any feature for specifying man pages.  I don't want to
install to an arbitrary location, but I need to be able to install to
$PREFIX/man/man1).

Is there a way to do this with setuptools, or do I need to keep using
distutils?  I would love to be able to use the "console_scripts"
feature, so it would be great if I could use setuptools, but obviously
the man pages are higher priority.  I feel like I must be missing
something obvious.  Thanks.


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868

From pje at telecommunity.com  Tue Jan 25 21:10:09 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 25 Jan 2011 15:10:09 -0500
Subject: [Distutils] setuptools and man pages
In-Reply-To: <20110125190313.GD26225@mcnabbs.org>
References: <20110125190313.GD26225@mcnabbs.org>
Message-ID: <20110125201019.D5EFC3A4075@sparrow.telecommunity.com>

At 12:03 PM 1/25/2011 -0700, Andrew McNabb wrote:
>I am maintaining a package that includes several scripts, and I recently
>added a man page.  Unfortunately, I was unable to figure out how to
>specify the man page with setuptools.  I ended up switching back to
>vanilla distutils, which allowed me to specify the man page in setup.py:
>
>     data_files=[('man/man1', ['man/man1/pssh.1'])]
>
>Is there an equivalent way to do this with setuptools?  The closest
>thing I could find in the setuptools documentation was, "Note, by the
>way, that this encapsulation of data files means that you can't actually
>install data files to some arbitrary location on a user's machine; this
>is a feature, not a bug."  I appreciate the well-intended thought, but I
>can't find any feature for specifying man pages.  I don't want to
>install to an arbitrary location, but I need to be able to install to
>$PREFIX/man/man1).
>
>Is there a way to do this with setuptools, or do I need to keep using
>distutils?  I would love to be able to use the "console_scripts"
>feature, so it would be great if I could use setuptools, but obviously
>the man pages are higher priority.  I feel like I must be missing
>something obvious.  Thanks.

Setuptools has a distutils-compatible installation mode:

    "setup.py install --single-version-externally-managed --record=somefile"

It's a bit awkward to type, but it should do what you want.


From amcnabb at mcnabbs.org  Tue Jan 25 22:41:52 2011
From: amcnabb at mcnabbs.org (Andrew McNabb)
Date: Tue, 25 Jan 2011 14:41:52 -0700
Subject: [Distutils] setuptools and man pages
In-Reply-To: <20110125201019.D5EFC3A4075@sparrow.telecommunity.com>
References: <20110125190313.GD26225@mcnabbs.org>
	<20110125201019.D5EFC3A4075@sparrow.telecommunity.com>
Message-ID: <20110125214152.GL26225@mcnabbs.org>

On Tue, Jan 25, 2011 at 03:10:09PM -0500, P.J. Eby wrote:
> 
> Setuptools has a distutils-compatible installation mode:
> 
>    "setup.py install --single-version-externally-managed --record=somefile"
> 
> It's a bit awkward to type, but it should do what you want.

But wouldn't this require all end users to know the incantation?
Presumably I could add the following to the top of setup.py:

sys.args += ['--single-version-externally-managed', '--record=somefile']

But that seems sort of dirty. :)

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868

From pje at telecommunity.com  Tue Jan 25 23:46:40 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 25 Jan 2011 17:46:40 -0500
Subject: [Distutils] setuptools and man pages
In-Reply-To: <20110125214152.GL26225@mcnabbs.org>
References: <20110125190313.GD26225@mcnabbs.org>
	<20110125201019.D5EFC3A4075@sparrow.telecommunity.com>
	<20110125214152.GL26225@mcnabbs.org>
Message-ID: <20110125224650.419013A4075@sparrow.telecommunity.com>

At 02:41 PM 1/25/2011 -0700, Andrew McNabb wrote:
>On Tue, Jan 25, 2011 at 03:10:09PM -0500, P.J. Eby wrote:
> >
> > Setuptools has a distutils-compatible installation mode:
> >
> >    "setup.py install --single-version-externally-managed --record=somefile"
> >
> > It's a bit awkward to type, but it should do what you want.
>
>But wouldn't this require all end users to know the incantation?

Well, those who want the man pages, certainly.  ;-)


>Presumably I could add the following to the top of setup.py:
>
>sys.args += ['--single-version-externally-managed', '--record=somefile']
>
>But that seems sort of dirty. :)

It also won't do anything if they're installing via another tool such 
as pip, easy_install, buildout, etc.


From amcnabb at mcnabbs.org  Tue Jan 25 23:53:13 2011
From: amcnabb at mcnabbs.org (Andrew McNabb)
Date: Tue, 25 Jan 2011 15:53:13 -0700
Subject: [Distutils] setuptools and man pages
In-Reply-To: <20110125224650.419013A4075@sparrow.telecommunity.com>
References: <20110125190313.GD26225@mcnabbs.org>
	<20110125201019.D5EFC3A4075@sparrow.telecommunity.com>
	<20110125214152.GL26225@mcnabbs.org>
	<20110125224650.419013A4075@sparrow.telecommunity.com>
Message-ID: <20110125225312.GE24845@mcnabbs.org>

On Tue, Jan 25, 2011 at 05:46:40PM -0500, P.J. Eby wrote:
> 
> It also won't do anything if they're installing via another tool
> such as pip, easy_install, buildout, etc.

Do each of those support some way to install man pages?

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868

From pje at telecommunity.com  Wed Jan 26 02:44:34 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 25 Jan 2011 20:44:34 -0500
Subject: [Distutils] setuptools and man pages
In-Reply-To: <20110125225312.GE24845@mcnabbs.org>
References: <20110125190313.GD26225@mcnabbs.org>
	<20110125201019.D5EFC3A4075@sparrow.telecommunity.com>
	<20110125214152.GL26225@mcnabbs.org>
	<20110125224650.419013A4075@sparrow.telecommunity.com>
	<20110125225312.GE24845@mcnabbs.org>
Message-ID: <20110126014444.474B23A4075@sparrow.telecommunity.com>

At 03:53 PM 1/25/2011 -0700, Andrew McNabb wrote:
>On Tue, Jan 25, 2011 at 05:46:40PM -0500, P.J. Eby wrote:
> >
> > It also won't do anything if they're installing via another tool
> > such as pip, easy_install, buildout, etc.
>
>Do each of those support some way to install man pages?

I imagine one could write a buildout plugin that would do it.  There 
was some discussion a while back about a buildout plugin for documentation.

Really, distutils2 is probably a better candidate for solving this 
problem, but it's not yet released and in any case not widely installed as yet.


From baiju.m.mail at gmail.com  Wed Jan 26 04:27:08 2011
From: baiju.m.mail at gmail.com (Baiju M)
Date: Wed, 26 Jan 2011 08:57:08 +0530
Subject: [Distutils] Fwd: [Catalog-sig] Trove categories for Buildout
	recipes and extensions
In-Reply-To: <AANLkTikJJz7_B4WG5NbAvSBmLsGEAHPXUMAKvoWKBM2t@mail.gmail.com>
References: <AANLkTinuQQkFOB+te6hFr3iqn1Gw=c=5YNmcm2CoLS0k@mail.gmail.com>
	<AANLkTikJJz7_B4WG5NbAvSBmLsGEAHPXUMAKvoWKBM2t@mail.gmail.com>
Message-ID: <AANLkTiktS0ABrDsfo2HQi1ZGkvHeHXsxPRWxZVVROen4@mail.gmail.com>

Hi,
    I am forwarding a mail from Catalog-sig regarding two new trove categories
for Buildout recipes and extensions. Those who publish Buildout recipes and
extensions to PyPI, please use the new trove classifiers in addition to
the existing "Framework :: Buildout".

If you are developing a recipe, use this classifier:

  classifiers=[
    ...
    "Framework :: Buildout",
    "Framework :: Buildout :: Recipe",
    ...
    ],

If you are developing an extension, use this classifier:

  classifiers=[
    ...
    "Framework :: Buildout",
    "Framework :: Buildout :: Extension",
    ...
    ],

If the distribution contains both extension and recipe, use:

  classifiers=[
    ...
    "Framework :: Buildout",
    "Framework :: Buildout :: Extension",
    "Framework :: Buildout :: Recipe",
    ...
    ],

Regards,
Baiju M


---------- Forwarded message ----------
From: Richard Jones <richard at python.org>
Date: Wed, Jan 26, 2011 at 4:08 AM
Subject: Re: [Catalog-sig] Trove categories for Buildout recipes and extensions
To: Baiju M <baiju.m.mail at gmail.com>
Cc: catalog-sig at python.org


On Tue, Jan 18, 2011 at 5:33 PM, Baiju M <baiju.m.mail at gmail.com> wrote:
> It would be nice if we can add two sub categories:
>
> ?Framework :: Buildout :: Recipe
> ?Framework :: Buildout :: Extension

There being no objections I've added these classifiers.


? ? Richard

From wichert at wiggy.net  Wed Jan 26 09:04:38 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Wed, 26 Jan 2011 09:04:38 +0100
Subject: [Distutils] Fwd: [Catalog-sig] Trove categories for Buildout
 recipes and extensions
In-Reply-To: <AANLkTiktS0ABrDsfo2HQi1ZGkvHeHXsxPRWxZVVROen4@mail.gmail.com>
References: <AANLkTinuQQkFOB+te6hFr3iqn1Gw=c=5YNmcm2CoLS0k@mail.gmail.com>	<AANLkTikJJz7_B4WG5NbAvSBmLsGEAHPXUMAKvoWKBM2t@mail.gmail.com>
	<AANLkTiktS0ABrDsfo2HQi1ZGkvHeHXsxPRWxZVVROen4@mail.gmail.com>
Message-ID: <4D3FD596.4090603@wiggy.net>

On 2011-1-26 04:27, Baiju M wrote:
> Hi,
>      I am forwarding a mail from Catalog-sig regarding two new trove categories
> for Buildout recipes and extensions. Those who publish Buildout recipes and
> extensions to PyPI, please use the new trove classifiers in addition to
> the existing "Framework :: Buildout".
>
> If you are developing a recipe, use this classifier:
>
>    classifiers=[
>      ...
>      "Framework :: Buildout",
>      "Framework :: Buildout :: Recipe",

Doesn't "Framework :: Buildout :: Recipe" already imply "Framework :: 
Buildout" ?


Wichert.


-- 
Wichert Akkerman <wichert at wiggy.net>   It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.

From martin at v.loewis.de  Wed Jan 26 10:40:31 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 26 Jan 2011 10:40:31 +0100
Subject: [Distutils] Fwd: [Catalog-sig] Trove categories for Buildout
 recipes and extensions
In-Reply-To: <4D3FD596.4090603@wiggy.net>
References: <AANLkTinuQQkFOB+te6hFr3iqn1Gw=c=5YNmcm2CoLS0k@mail.gmail.com>	<AANLkTikJJz7_B4WG5NbAvSBmLsGEAHPXUMAKvoWKBM2t@mail.gmail.com>	<AANLkTiktS0ABrDsfo2HQi1ZGkvHeHXsxPRWxZVVROen4@mail.gmail.com>
	<4D3FD596.4090603@wiggy.net>
Message-ID: <4D3FEC0F.4000406@v.loewis.de>


>> If you are developing a recipe, use this classifier:
>>
>>    classifiers=[
>>      ...
>>      "Framework :: Buildout",
>>      "Framework :: Buildout :: Recipe",
> 
> Doesn't "Framework :: Buildout :: Recipe" already imply "Framework ::
> Buildout" ?

If it indeed could have meant "Framework :: Buildout :: Extension"
instead, and if "Framework :: Buildout :: Extension" and
"Framework :: Buildout :: Recipe" are indeed different things, then:
no.

Regards,
Martin

From wichert at wiggy.net  Wed Jan 26 10:42:19 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Wed, 26 Jan 2011 10:42:19 +0100
Subject: [Distutils] Fwd: [Catalog-sig] Trove categories for Buildout
 recipes and extensions
In-Reply-To: <4D3FEC0F.4000406@v.loewis.de>
References: <AANLkTinuQQkFOB+te6hFr3iqn1Gw=c=5YNmcm2CoLS0k@mail.gmail.com>	<AANLkTikJJz7_B4WG5NbAvSBmLsGEAHPXUMAKvoWKBM2t@mail.gmail.com>	<AANLkTiktS0ABrDsfo2HQi1ZGkvHeHXsxPRWxZVVROen4@mail.gmail.com>
	<4D3FD596.4090603@wiggy.net> <4D3FEC0F.4000406@v.loewis.de>
Message-ID: <4D3FEC7B.20703@wiggy.net>

On 1/26/11 10:40 , "Martin v. L?wis" wrote:
>
>>> If you are developing a recipe, use this classifier:
>>>
>>>     classifiers=[
>>>       ...
>>>       "Framework :: Buildout",
>>>       "Framework :: Buildout :: Recipe",
>>
>> Doesn't "Framework :: Buildout :: Recipe" already imply "Framework ::
>> Buildout" ?
>
> If it indeed could have meant "Framework :: Buildout :: Extension"
> instead, and if "Framework :: Buildout :: Extension" and
> "Framework :: Buildout :: Recipe" are indeed different things, then:
> no.

That's not what I meant exactly. What I meant that is you declare a 
Trove classifier "A :: B :: C" aren't you implicitly declaring "A :: B"
and "A" as well, so you don't need to specify them separately?

Wichert.

From martin at v.loewis.de  Wed Jan 26 10:52:59 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 26 Jan 2011 10:52:59 +0100
Subject: [Distutils] Fwd: [Catalog-sig] Trove categories for Buildout
 recipes and extensions
In-Reply-To: <4D3FEC7B.20703@wiggy.net>
References: <AANLkTinuQQkFOB+te6hFr3iqn1Gw=c=5YNmcm2CoLS0k@mail.gmail.com>	<AANLkTikJJz7_B4WG5NbAvSBmLsGEAHPXUMAKvoWKBM2t@mail.gmail.com>	<AANLkTiktS0ABrDsfo2HQi1ZGkvHeHXsxPRWxZVVROen4@mail.gmail.com>
	<4D3FD596.4090603@wiggy.net> <4D3FEC0F.4000406@v.loewis.de>
	<4D3FEC7B.20703@wiggy.net>
Message-ID: <4D3FEEFB.2000006@v.loewis.de>

>>> Doesn't "Framework :: Buildout :: Recipe" already imply "Framework ::
>>> Buildout" ?
>>
>> If it indeed could have meant "Framework :: Buildout :: Extension"
>> instead, and if "Framework :: Buildout :: Extension" and
>> "Framework :: Buildout :: Recipe" are indeed different things, then:
>> no.
> 
> That's not what I meant exactly. What I meant that is you declare a
> Trove classifier "A :: B :: C" aren't you implicitly declaring "A :: B"
> and "A" as well, so you don't need to specify them separately?

Oops, I read it reverse, sorry.

It unfortunately depends on who is interpreting the data. For
compatibility, I would err on the safe side and just include the
old classifier as well. But you are right; it would be redundant.

Regards,
Martin


From merwok at netwok.org  Wed Jan 26 12:54:24 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 26 Jan 2011 12:54:24 +0100
Subject: [Distutils] Fwd: [Catalog-sig] Trove categories for Buildout
 recipes and extensions
In-Reply-To: <4D3FEC7B.20703@wiggy.net>
References: <AANLkTinuQQkFOB+te6hFr3iqn1Gw=c=5YNmcm2CoLS0k@mail.gmail.com>	<AANLkTikJJz7_B4WG5NbAvSBmLsGEAHPXUMAKvoWKBM2t@mail.gmail.com>	<AANLkTiktS0ABrDsfo2HQi1ZGkvHeHXsxPRWxZVVROen4@mail.gmail.com>	<4D3FD596.4090603@wiggy.net>
	<4D3FEC0F.4000406@v.loewis.de> <4D3FEC7B.20703@wiggy.net>
Message-ID: <4D400B70.5090706@netwok.org>

>>> Doesn't "Framework :: Buildout :: Recipe" already imply "Framework ::
>>> Buildout" ?
>> [...]
> That's not what I meant exactly. What I meant that is you declare a 
> Trove classifier "A :: B :: C" aren't you implicitly declaring "A :: B"
> and "A" as well, so you don't need to specify them separately?

You?re not implicitly declaring ?A? because it is not a classifier: They
all have at least two parts.  In this example:

	Topic :: Software Development :: Version Control :: CVS

these implied classifiers may be useful in your application:

	Topic :: Software Development :: Version Control
	Topic :: Software Development

however, ?Topic? alone is not a classifier, and is not very useful
(?this distribution defines one topic?).

Maybe we should provide a module in distutils2 to make useful operations
with Trove classifiers strings.

Regards

From tom at aratyn.name  Wed Jan 26 16:25:54 2011
From: tom at aratyn.name (Tom Aratyn)
Date: Wed, 26 Jan 2011 10:25:54 -0500
Subject: [Distutils] Buildout and non-pypi hosted packages
Message-ID: <AANLkTin8FxesCGX9SLn7qAd7TbVOw4zP1edOfqKn3i+b@mail.gmail.com>

Hello,

I work for an organization which would like to use buildout but we're
hitting a problem with buildout and pyrtf (which is not hosted in the
cheeseshop but is available off a url form sourceforge). Pip has no
problem with this but I'm not sure how to get buildout to understand
it.

We're listing all our dependencies using install_requires. Is there a
way to do this?

Cheers,

Tom

From benji at benjiyork.com  Wed Jan 26 16:33:28 2011
From: benji at benjiyork.com (Benji York)
Date: Wed, 26 Jan 2011 10:33:28 -0500
Subject: [Distutils] Buildout and non-pypi hosted packages
In-Reply-To: <AANLkTin8FxesCGX9SLn7qAd7TbVOw4zP1edOfqKn3i+b@mail.gmail.com>
References: <AANLkTin8FxesCGX9SLn7qAd7TbVOw4zP1edOfqKn3i+b@mail.gmail.com>
Message-ID: <AANLkTikcVNoOTQW7VYmvZ8T=1uCF1HoUk3-K_+3se5pD@mail.gmail.com>

On Wed, Jan 26, 2011 at 10:25 AM, Tom Aratyn <tom at aratyn.name> wrote:
> I work for an organization which would like to use buildout but we're
> hitting a problem with buildout and pyrtf (which is not hosted in the
> cheeseshop but is available off a url form sourceforge). Pip has no
> problem with this but I'm not sure how to get buildout to understand
> it.

See http://pypi.python.org/pypi/zc.buildout#finding-distributions,
especially the "find-links" option.
-- 
Benji York

From tseaver at palladion.com  Wed Jan 26 16:44:17 2011
From: tseaver at palladion.com (Tres Seaver)
Date: Wed, 26 Jan 2011 10:44:17 -0500
Subject: [Distutils] Buildout and non-pypi hosted packages
In-Reply-To: <AANLkTin8FxesCGX9SLn7qAd7TbVOw4zP1edOfqKn3i+b@mail.gmail.com>
References: <AANLkTin8FxesCGX9SLn7qAd7TbVOw4zP1edOfqKn3i+b@mail.gmail.com>
Message-ID: <ihpfgh$9p3$1@dough.gmane.org>

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

On 01/26/2011 10:25 AM, Tom Aratyn wrote:
> Hello,
> 
> I work for an organization which would like to use buildout but we're
> hitting a problem with buildout and pyrtf (which is not hosted in the
> cheeseshop but is available off a url form sourceforge). Pip has no
> problem with this but I'm not sure how to get buildout to understand
> it.
> 
> We're listing all our dependencies using install_requires. Is there a
> way to do this?

Check out the options here:

 http://pypi.python.org/pypi/zc.buildout#finding-distributions


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.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1AQVEACgkQ+gerLs4ltQ5aJgCgnez9eK6UNNsAH2UlxlH9O6TN
AbcAoKeiIOltlV9vLstKaLQ1fXbhEHfl
=TTff
-----END PGP SIGNATURE-----


From tom at aratyn.name  Mon Jan 31 05:28:46 2011
From: tom at aratyn.name (Tom Aratyn)
Date: Sun, 30 Jan 2011 23:28:46 -0500
Subject: [Distutils] Buildout and non-pypi hosted packages
In-Reply-To: <ihpfgh$9p3$1@dough.gmane.org>
References: <AANLkTin8FxesCGX9SLn7qAd7TbVOw4zP1edOfqKn3i+b@mail.gmail.com>
	<ihpfgh$9p3$1@dough.gmane.org>
Message-ID: <AANLkTikm1R1sfuXkR0HcxpubCCfHoAemW5DvNarDien-@mail.gmail.com>

That solved it! Thanks for the help!

On Wed, Jan 26, 2011 at 10:44 AM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/26/2011 10:25 AM, Tom Aratyn wrote:
>> Hello,
>>
>> I work for an organization which would like to use buildout but we're
>> hitting a problem with buildout and pyrtf (which is not hosted in the
>> cheeseshop but is available off a url form sourceforge). Pip has no
>> problem with this but I'm not sure how to get buildout to understand
>> it.
>>
>> We're listing all our dependencies using install_requires. Is there a
>> way to do this?
>
> Check out the options here:
>
> ?http://pypi.python.org/pypi/zc.buildout#finding-distributions
>
>
> 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.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1AQVEACgkQ+gerLs4ltQ5aJgCgnez9eK6UNNsAH2UlxlH9O6TN
> AbcAoKeiIOltlV9vLstKaLQ1fXbhEHfl
> =TTff
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>