From setuptools at bugs.python.org  Sun Aug  5 20:18:59 2012
From: setuptools at bugs.python.org (Valentin Lorentz)
Date: Sun, 05 Aug 2012 18:18:59 +0000
Subject: [Distutils] [issue143] Cannot install: ValueError: bad marshal data
	(unknown type	code)
Message-ID: <1344190739.85.0.781078076263.issue143@psf.upfronthosting.co.za>


New submission from Valentin Lorentz:

Hi,

I cannot use setuptools with use_2to3=True. The traceback as attachment, and here is my setup.py: http://paste.progval.net/show/93/ (I cannot add another attachment)

fixes_2to3 is a directory containing fixes and this __init__.py :
from . import fix_def_iteritems, fix_def_itervalues, fix_def_iterkeys, fix_reload
from lib2to3.fixes import *

I use setuptools 0.6.24-1 from Debian GNU/Linux Sid, with Python 3.2.3-4.

Regards,
Valentin

----------
files: setuptools_traceback.txt
messages: 690
nosy: ProgVal
priority: bug
status: unread
title: Cannot install: ValueError: bad marshal data (unknown type code)
Added file: http://bugs.python.org/setuptools/file87/setuptools_traceback.txt

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue143>
_______________________________________________
-------------- next part --------------
Traceback (most recent call last):
  File setup.py, line 210, in <module>
    use_2to3_fixers=['fixes_2to3']
  File /usr/lib/python3.2/distutils/core.py, line 148, in setup
    dist.run_commands()
  File /usr/lib/python3.2/distutils/dist.py, line 917, in run_commands
    self.run_command(cmd)
  File /usr/lib/python3.2/distutils/dist.py, line 936, in run_command
    cmd_obj.run()
  File /usr/lib/python3/dist-packages/setuptools/command/install.py, line 73, in run
    self.do_egg_install()
  File /usr/lib/python3/dist-packages/setuptools/command/install.py, line 93, in do_egg_install
    self.run_command('bdist_egg')
  File /usr/lib/python3.2/distutils/cmd.py, line 313, in run_command
    self.distribution.run_command(command)
  File /usr/lib/python3.2/distutils/dist.py, line 936, in run_command
    cmd_obj.run()
  File /usr/lib/python3/dist-packages/setuptools/command/bdist_egg.py, line 227, in run
    os.path.join(archive_root,'EGG-INFO'), self.zip_safe()
  File /usr/lib/python3/dist-packages/setuptools/command/bdist_egg.py, line 266, in zip_safe
    return analyze_egg(self.bdist_dir, self.stubs)
  File /usr/lib/python3/dist-packages/setuptools/command/bdist_egg.py, line 402, in analyze_egg
    safe = scan_module(egg_dir, base, name, stubs) and safe
  File /usr/lib/python3/dist-packages/setuptools/command/bdist_egg.py, line 429, in scan_module
    code = marshal.load(f);  f.close()
ValueError: bad marshal data (unknown type code)

From dholth at gmail.com  Mon Aug  6 23:09:14 2012
From: dholth at gmail.com (Daniel Holth)
Date: Mon, 6 Aug 2012 17:09:14 -0400
Subject: [Distutils] PEP proposal: multi-interpreter naming convention for
	built distributions
Message-ID: <CAG8k2+4TdPo=vU7fYhKFxbCyASCdzek_ShYgkcpjDO76sHQatA@mail.gmail.com>

I propose a three-part Implementation, ABI, Architecture naming scheme
for built distributions as a new Python standard. The full list of
allowed tags would need to be fleshed out for this to be completed,
but I don't know enough about the needs of each implementation.

https://bitbucket.org/dholth/python-peps/src/tip/pep-CTAG.txt

Summary

Built distributions need a file naming scheme that indicates the
Python implementation, the ABI, and the platform. Today pypy and
CPython's "setup.py bdist" generate the same filename but incompatible
bdists. This is a problem if you would like to share the two bdists in the
same folder. Instead, they should generate distinct bdist filenames because
one won't work with the other implementation. This PEP only specifies
a tagging system that could be used in bdist filenames.

This mostly considers the needs of CPython. I hope to get input from
the other implementation communities, or in fact anyone at all.

Thanks,

Daniel Holth

From ralf at systemexit.de  Tue Aug  7 22:21:06 2012
From: ralf at systemexit.de (Ralf Schmitt)
Date: Tue, 07 Aug 2012 22:21:06 +0200
Subject: [Distutils] [ANNOUNCE] pypiserver 0.6.1 - minimal private pypi
	server
Message-ID: <874noe1mj1.fsf@debian.lan>

Hi,

I've just uploaded pypiserver 0.6.1 to the python package index.

pypiserver is a minimal PyPI compatible server. It can be used to serve
a set of packages and eggs to easy_install or pip.

pypiserver is easy to install (i.e. just easy_install pypiserver). It
doesn't have any external dependencies.

http://pypi.python.org/pypi/pypiserver/ should contain enough
information to easily get you started running your own PyPI server in a
few minutes.

The code is available on github: https://github.com/schmir/pypiserver

Changes in version 0.6.1
------------------------
- make 'python setup.py register' work
- added init scripts to start pypiserver on ubuntu/opensuse


-- 
Cheers
Ralf

From doko at ubuntu.com  Wed Aug  8 13:58:31 2012
From: doko at ubuntu.com (Matthias Klose)
Date: Wed, 08 Aug 2012 13:58:31 +0200
Subject: [Distutils] PEP proposal: multi-interpreter naming convention
 for built distributions
In-Reply-To: <CAG8k2+4TdPo=vU7fYhKFxbCyASCdzek_ShYgkcpjDO76sHQatA@mail.gmail.com>
References: <CAG8k2+4TdPo=vU7fYhKFxbCyASCdzek_ShYgkcpjDO76sHQatA@mail.gmail.com>
Message-ID: <50225467.8010707@ubuntu.com>

On 06.08.2012 23:09, Daniel Holth wrote:
> I propose a three-part Implementation, ABI, Architecture naming scheme
> for built distributions as a new Python standard. The full list of
> allowed tags would need to be fleshed out for this to be completed,
> but I don't know enough about the needs of each implementation.

Afaics, this doesn't support the stable ABI, as defined in PEP 384.

  Matthias


From dholth at gmail.com  Wed Aug  8 14:19:02 2012
From: dholth at gmail.com (Daniel Holth)
Date: Wed, 8 Aug 2012 08:19:02 -0400
Subject: [Distutils] PEP proposal: multi-interpreter naming convention
 for built distributions
In-Reply-To: <50225467.8010707@ubuntu.com>
References: <CAG8k2+4TdPo=vU7fYhKFxbCyASCdzek_ShYgkcpjDO76sHQatA@mail.gmail.com>
	<50225467.8010707@ubuntu.com>
Message-ID: <CAG8k2+5We-MuLDdJR=rwAmuu4cfknAK5YVyRpBvKDHqS6+eE3g@mail.gmail.com>

> Afaics, this doesn't support the stable ABI, as defined in PEP 384.

I've fixed that bit and am continuing the discussion on python-ideas.

From admin at designers-guide.com  Wed Aug  8 21:22:58 2012
From: admin at designers-guide.com (Ken Kundert)
Date: Wed, 8 Aug 2012 12:22:58 -0700
Subject: [Distutils] man pages
Message-ID: <20120808192258.GA31410@dgc21.designers-guide.com>

All,
    I am converting from the old setup tools to distribute and am having trouble 
with installing man pages for my project.

The relevant part of my setup script is:

setup(
  ...,
    scripts=['ec'],
    data_files=[
        ('man/man1', ['ec.1'])
    ]
)

When I would install using the --user options, it would put the executable in 
~/.local/bin and the man pages in ~/.local/man. In this way, once ~/.local/bin 
is on my path, the man command would find the man page. However, when I use 
distribute, it is now putting the man pages in the egg (in 
~/.local/lib/python2.7/site-packages/ec-1.0-py2.7.egg/man). The documentation 
seems to suggest that this is a feature rather than a bug, and I accept that, 
but man pages seem special, like scripts. They need to go into a particular 
place in order for the man command to find them, and putting them inside the egg 
is not helpful.

Does anybody have a suggestion on how to get the man pages to end up where they 
belong?

-Ken

Sorry if this has already been discussed. I cannot figure out any easy way to 
search the mailing list archives for this information.


From admin at designers-guide.com  Thu Aug  9 02:54:46 2012
From: admin at designers-guide.com (Ken Kundert)
Date: Wed, 8 Aug 2012 17:54:46 -0700
Subject: [Distutils] Can I have distribute build a file for me?
Message-ID: <20120809005445.GB31410@dgc21.designers-guide.com>

Currently I am use an import in my setup script to build a file I need during 
the install. Specifically:

#!/usr/bin/env python
import distribute_setup
distribute_setup.use_setuptools()
from setuptools import setup

import manpage # simply importing manpage creates the ec.1 as a side effect

setup(
    name='ec',
    version='1.0',
    ...,
    data_files=[('man/man1', ['ec.1'])],
    ...
)

However, I require that docutils be installed in advance otherwise the import 
will fail. To resolve this, I would like to use setup_requires='docutils>0.7'.  
For this to be effective, I will have to arrange things so that the import 
occurs during the evaluation of setup(). Is that possible?

I have created an ugly hack that works by calling setup() twice ...

setup(
    name='ec',
    version='1.0',
    ...,
    setup_requires='docutils >= 0.7',
    ...)
import manpage # simply importing manpage creates the ec.1 as a side effect 
setup(
    name='ec',
    version='1.0',
    ...,
    data_files=[('man/man1', ['ec.1'])],
    ...)

But I cannot help but believe there must be a better way.
Is there some way add a hook to setup to get it to do the import for me after 
setup_requires has been processed?
If not, is there some way to install docutils if needed before I call setup()?

-Ken

From rbpark at exolucere.ca  Thu Aug  9 03:33:50 2012
From: rbpark at exolucere.ca (Robert Park)
Date: Wed, 8 Aug 2012 20:33:50 -0500
Subject: [Distutils] Can I have distribute build a file for me?
In-Reply-To: <20120809005445.GB31410@dgc21.designers-guide.com>
References: <20120809005445.GB31410@dgc21.designers-guide.com>
Message-ID: <CAL3PwKw-CGVrzvS6A-=vp1t1oFd1MyDkbWeuqed=o08Tzaw_LA@mail.gmail.com>

On Wed, Aug 8, 2012 at 7:54 PM, Ken Kundert <admin at designers-guide.com> wrote:
> But I cannot help but believe there must be a better way.
> Is there some way add a hook to setup to get it to do the import for me after
> setup_requires has been processed?
> If not, is there some way to install docutils if needed before I call setup()?

I had a similar problem in which I needed to autogenerate the contents
of a .py file at build-time, and I accomplished it by overriding
build_py. setup then calls my build_py module which overwrites the
particular .py file without harming any other ones. You can see my
code here:

https://github.com/robru/gottengeography/blob/master/setup.py#L33

No ugly hacks necessary to call setup twice, it's a bit verbose but it works.

In your case, it should be essentially trivial to subclass `build`
(instead of build_py), and then to simply `import manpage` in your
custom build module, which setup will then call on it's own. Just
follow the pattern you see in my setup.py.

-- 
http://gottengeography.ca

From admin at designers-guide.com  Thu Aug  9 20:14:01 2012
From: admin at designers-guide.com (Ken Kundert)
Date: Thu, 9 Aug 2012 11:14:01 -0700
Subject: [Distutils] Can I have distribute build a file for me?
In-Reply-To: <CAL3PwKw-CGVrzvS6A-=vp1t1oFd1MyDkbWeuqed=o08Tzaw_LA@mail.gmail.com>
References: <20120809005445.GB31410@dgc21.designers-guide.com>
	<CAL3PwKw-CGVrzvS6A-=vp1t1oFd1MyDkbWeuqed=o08Tzaw_LA@mail.gmail.com>
Message-ID: <20120809181401.GC31410@dgc21.designers-guide.com>

Robert,
    Thanks that was very helpful. Here is what I have come up with:

#!/usr/bin/env python
import distribute_setup
distribute_setup.use_setuptools()
from setuptools import setup
from distutils.command.build import build as _build

class build(_build):
    # Overload the built-in build command such that manpage (ec.1) is created
    # during the build phase
    def run(self):
	import manpage # simply importing the manpage creates the manpage as a side effect
	_build.initialize_options(self)

setup(
    name='ec',
    ...,
    data_files=[
	('man/man1', ['ec.1'])
    ],
    setup_requires='docutils >= 0.7',
    install_requires='python >= 2.6',
    cmdclass={'build': build}
)

Initially I overloaded the run() method for build, but that only worked if 
I explicitly specified 'build' when I ran setup (i.e., 'python setup.py build').  
It did not work if I specified 'install', which surprised me because I thought 
install automatically ran the build command if it is needed. While it might, it 
does not execute build's run() method, even though I thoroughly cleaned the 
install directory before I ran install. So instead I overloaded 
initialize_options().  I don't know if this is a good approach, because I am not 
sure initialize_options() is always called.  I could also overload run() in the 
install class, but I decided against it because it seems more in keeping of the 
spirit of the build and install commands that building the manpage be done in 
the build phase.

Is this what you were thinking? Is there any way to improve on this approach?

-Ken

From rbpark at exolucere.ca  Thu Aug  9 22:10:30 2012
From: rbpark at exolucere.ca (Robert Park)
Date: Thu, 9 Aug 2012 15:10:30 -0500
Subject: [Distutils] Can I have distribute build a file for me?
In-Reply-To: <20120809181401.GC31410@dgc21.designers-guide.com>
References: <20120809005445.GB31410@dgc21.designers-guide.com>
	<CAL3PwKw-CGVrzvS6A-=vp1t1oFd1MyDkbWeuqed=o08Tzaw_LA@mail.gmail.com>
	<20120809181401.GC31410@dgc21.designers-guide.com>
Message-ID: <CAL3PwKz2RgP7qZOvT6Pt8qed6HiRTSXNkr20TEyc4C_qtHyufg@mail.gmail.com>

On Thu, Aug 9, 2012 at 1:14 PM, Ken Kundert <admin at designers-guide.com> wrote:
> Is this what you were thinking? Is there any way to improve on this approach?

This is exactly what I had in mind, yes. Unfortunately I don't know
enough about distutils to say why build.run() doesn't get called or
whether initialize_options() is a good place to do this. Hopefully
somebody else on this list can help you out with those questions.


-- 
http://gottengeography.ca

From admin at designers-guide.com  Thu Aug  9 23:51:39 2012
From: admin at designers-guide.com (Ken Kundert)
Date: Thu, 9 Aug 2012 14:51:39 -0700
Subject: [Distutils] man pages
In-Reply-To: <20120808192258.GA31410@dgc21.designers-guide.com>
References: <20120808192258.GA31410@dgc21.designers-guide.com>
Message-ID: <20120809215139.GD31410@dgc21.designers-guide.com>

Well, I have come up with a solution for how to get the man page in the right 
place, but I am not very happy with it. Here it is:

#!/usr/bin/env python
import distribute_setup
distribute_setup.use_setuptools()
from setuptools import setup

# Use the distutils version of the install command rather than the one from
# distribute because it puts the man page in an inaccessible place
from distutils.command.install import install

setup(
    name='ec',
    ...,
    cmdclass = {'install': install},
    data_files=[
        ('man/man1', ['ec.1'])
    ]
)

Here, I use cmdclass to replace distribute's version of the install command with 
the older version from distutils.

Rather than replace install, I did try to supplement it with code that simply 
moved the man page to the right place, but from within install there is no easy 
way to get the name of the directory where the data files are placed. The 
resulting code seemed overly complicated and fragile, so I abandoned that 
approach.

While I appreciate the reason why the data files are now placed in the 
site-packages directory, this change seems to break support for man pages 
(unless I am missing something).  And since man pages should be supplied for all 
executables, this seems like a serious issue. Perhaps there should be dedicated 
support for man pages in much the same way there is dedicated support for 
scripts.

-Ken

From amcnabb at mcnabbs.org  Fri Aug 10 00:27:44 2012
From: amcnabb at mcnabbs.org (Andrew McNabb)
Date: Thu, 9 Aug 2012 16:27:44 -0600
Subject: [Distutils] man pages
In-Reply-To: <20120809215139.GD31410@dgc21.designers-guide.com>
References: <20120808192258.GA31410@dgc21.designers-guide.com>
	<20120809215139.GD31410@dgc21.designers-guide.com>
Message-ID: <20120809222744.GA4195@mcnabbs.org>

On Thu, Aug 09, 2012 at 02:51:39PM -0700, Ken Kundert wrote:
> 
> While I appreciate the reason why the data files are now placed in the 
> site-packages directory, this change seems to break support for man pages 
> (unless I am missing something).  And since man pages should be supplied for all 
> executables, this seems like a serious issue. Perhaps there should be dedicated 
> support for man pages in much the same way there is dedicated support for 
> scripts.

I share this concern, and the lack of support for man pages is why I am
stuck using distutils instead of setuptools or distribute.

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

From aclark at aclark.net  Mon Aug 13 23:31:28 2012
From: aclark at aclark.net (Alex Clark)
Date: Mon, 13 Aug 2012 17:31:28 -0400
Subject: [Distutils] Buildout 1.6 release tomorrow
Message-ID: <k0brnf$mj$1@dough.gmane.org>

Hi,


Please weigh in now if you have any serious concerns re: a Buildout 1.6 
release, as described here:

- http://blog.aclark.net/2012/08/13/bootstrapping-a-buildout-1-6-release/



Alex



-- 
Alex Clark ? http://pythonpackages.com/ONE_CLICK


From marius at pov.lt  Tue Aug 14 10:49:41 2012
From: marius at pov.lt (Marius Gedminas)
Date: Tue, 14 Aug 2012 11:49:41 +0300
Subject: [Distutils] Buildout 1.6 release tomorrow
In-Reply-To: <k0brnf$mj$1@dough.gmane.org>
References: <k0brnf$mj$1@dough.gmane.org>
Message-ID: <20120814084940.GB17535@fridge.pov.lt>

On Mon, Aug 13, 2012 at 05:31:28PM -0400, Alex Clark wrote:
> Please weigh in now if you have any serious concerns re: a Buildout
> 1.6 release, as described here:
> 
> - http://blog.aclark.net/2012/08/13/bootstrapping-a-buildout-1-6-release/

Sounds excellent!

My favourite upcoming changes are:

- https://bugs.launchpad.net/bugs/697913 : Buildout doesn't honor exit code
  from scripts. Fixed.

- Handle both addition and subtraction of elements (+= and -=) on the same key
  in the same section.

Marius Gedminas
-- 
Lisp-style macros [...] are to C-style macros what Emacs is to cat.
                -- Jacek Generowicz
-------------- 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/20120814/eca6c98c/attachment.pgp>

From dholth at gmail.com  Tue Aug 14 21:48:37 2012
From: dholth at gmail.com (Daniel Holth)
Date: Tue, 14 Aug 2012 15:48:37 -0400
Subject: [Distutils] Action on Metadata 1.2 edits?
Message-ID: <CAG8k2+4F4JmaepaQwfqo5vLdJxVC4fKBj4v-2CuHedoO75xv3g@mail.gmail.com>

Python PEPs merged the Metadata 1.2 edits the first time, but they
were backed out pending a discussion. Is a committer available to do
one of the following?

a) Let the Python PEPs maintainers know it's OK to merge the Metadata
1.2 edits (minus the X- fields) to allow Provides-Extra:, extra =
conditions on Requires-Dist, and Setup-Requires-Dist
b) Move these changes into a new Metadata 1.3

The edits are waiting to be pulled from
https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068c0235302b0614058b7dccf30b0ce

Thanks,

Daniel Holth

From reinout at vanrees.org  Tue Aug 14 22:58:42 2012
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 14 Aug 2012 22:58:42 +0200
Subject: [Distutils] Buildout 1.6 release tomorrow
In-Reply-To: <k0brnf$mj$1@dough.gmane.org>
References: <k0brnf$mj$1@dough.gmane.org>
Message-ID: <k0ee60$h57$1@dough.gmane.org>

On 13-08-12 23:31, Alex Clark wrote:
> Hi,
>
>
> Please weigh in now if you have any serious concerns re: a Buildout 1.6
> release, as described here:

The only thing: make sure the 1.4.4 buildout + special bootstrap file 
keeps working. The one that prevents 1.5.x from being used.

I suspect a 1.6 buildout won't break it, but I thought I'd mention it 
just to make sure :-)



Reinout

-- 
Reinout van Rees                    http://reinout.vanrees.org/
reinout at vanrees.org             http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"


From aclark at aclark.net  Wed Aug 15 01:29:02 2012
From: aclark at aclark.net (Alex Clark)
Date: Tue, 14 Aug 2012 19:29:02 -0400
Subject: [Distutils] Buildout 1.6 release tomorrow
In-Reply-To: <k0ee60$h57$1@dough.gmane.org>
References: <k0brnf$mj$1@dough.gmane.org> <k0ee60$h57$1@dough.gmane.org>
Message-ID: <k0en00$ldu$1@dough.gmane.org>

On 8/14/12 4:58 PM, Reinout van Rees wrote:
> On 13-08-12 23:31, Alex Clark wrote:
>> Hi,
>>
>>
>> Please weigh in now if you have any serious concerns re: a Buildout 1.6
>> release, as described here:
>
> The only thing: make sure the 1.4.4 buildout + special bootstrap file
> keeps working. The one that prevents 1.5.x from being used.
>
> I suspect a 1.6 buildout won't break it, but I thought I'd mention it
> just to make sure :-)



I have no idea what that means :-) (I use 1.5.2) Can you explain? There 
is a corresponding bootstrap.py file with each release, IIUC. If the 
"special bootstrap file" is the bootstrap.py that was released with 
1.4.4, then I understand. Otherwise, I probably don't. It certainly 
seems reasonable that a 1.4.x release was made containing 
"prophylactics" for 1.5.x? and without looking I'm guessing those 
prophylactics entail primarily specifying the correct URL to download 
the 1.4.4 distribution?



Alex



>
>
>
> Reinout
>


-- 
Alex Clark ? http://pythonpackages.com/ONE_CLICK


From jim at zope.com  Wed Aug 15 02:26:53 2012
From: jim at zope.com (Jim Fulton)
Date: Tue, 14 Aug 2012 20:26:53 -0400
Subject: [Distutils] Buildout 1.6 release tomorrow
In-Reply-To: <k0en00$ldu$1@dough.gmane.org>
References: <k0brnf$mj$1@dough.gmane.org> <k0ee60$h57$1@dough.gmane.org>
	<k0en00$ldu$1@dough.gmane.org>
Message-ID: <CAPDm-Fgz1WcfjHVMUapC8SzW3X9Q2gFHsJmXuP0-jnNorAkUjA@mail.gmail.com>

On Tue, Aug 14, 2012 at 7:29 PM, Alex Clark <aclark at aclark.net> wrote:
> On 8/14/12 4:58 PM, Reinout van Rees wrote:
>>
>> On 13-08-12 23:31, Alex Clark wrote:
>>>
>>> Hi,
>>>
>>>
>>> Please weigh in now if you have any serious concerns re: a Buildout 1.6
>>> release, as described here:
>>
>>
>> The only thing: make sure the 1.4.4 buildout + special bootstrap file
>> keeps working. The one that prevents 1.5.x from being used.
>>
>> I suspect a 1.6 buildout won't break it, but I thought I'd mention it
>> just to make sure :-)
>
>
>
>
> I have no idea what that means :-) (I use 1.5.2) Can you explain? There is a
> corresponding bootstrap.py file with each release, IIUC. If the "special
> bootstrap file" is the bootstrap.py that was released with 1.4.4, then I
> understand. Otherwise, I probably don't. It certainly seems reasonable that
> a 1.4.x release was made containing "prophylactics" for 1.5.x? and without
> looking I'm guessing those prophylactics entail primarily specifying the
> correct URL to download the 1.4.4 distribution?

And some other things.  I good way to test this would be to put 1.6 in
your download cache (before uploading it), bootstrap 1.4 and make sure
it doesn't upgrade itself to 1.5.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm

From lele at metapensiero.it  Wed Aug 15 16:36:56 2012
From: lele at metapensiero.it (Lele Gaifax)
Date: Wed, 15 Aug 2012 16:36:56 +0200
Subject: [Distutils] Struggling with a modular buildout configuration
Message-ID: <87lihgp6gn.fsf@metapensiero.it>

Hi all,

I'm trying to setup a modular buildout configuration, but I'm hitting my
head on an invisible wall...

Basically, I'd like to have a top-level buildout.cfg that "collects"
settings from various "subprojects"; in particular, each subproject may
"augment" a set of eggs, some of which may be defined as "develop" (in
buildout parlance). Finally, with a single "zc.recipe.egg" I wanna
install a custom interpreter with all those eggs inside.

So, I have the top-level configuration that uses "extends" to include a
"projects.cfg":

  [buildout]
  extends = base.cfg projects.cfg
  
that in turn brings in the various subprojects snippets thru "extends":

  [buildout]
  extends = src/this-project.cfg src/that-project.cfg

these snippets typically contain a section like

  [projects]
  eggs += this-project-egg some-other-dependency-egg
  develop += src/this-project
  parts += this-project-specific-part

  [this-project-specific-part]
  ...

The problem I'm having is that for incomprensible (to me, of course :)
reason some of those settings do not "emerge" at the top level (others
do!), as if a later "extends" is clobbering a previous one.

I built a minimalistic example [1] that shows the unexpected behaviour;
doing a "buildout annotate" I get something like the following:

  Annotated sections
  ==================

  [buildout]
  ...
  develop= ${projects:develop}
      /tmp/tb/buildout.cfg
  parts= ${projects:parts}
      /tmp/tb/buildout.cfg
  ...

  [extra-parts-from-proj2]

  [projects]
  develop= 
  src/proj2
  +=  /tmp/tb/src/proj2/devel.cfg
  eggs= 
  extra-needed-by-proj1
  proj1
  proj2
  +=  /tmp/tb/src/proj1/devel.cfg
  +=  /tmp/tb/src/proj1/base.cfg
  +=  /tmp/tb/src/proj2/base.cfg
  parts= 
  extra-parts-from-proj2
  +=  /tmp/tb/src/proj2/devel.cfg

  [python]
  eggs= ${projects:eggs}
      /tmp/tb/base.cfg
  interpreter= python
      /tmp/tb/base.cfg
  recipe= zc.recipe.egg
      /tmp/tb/base.cfg

If you look at the [projects] section, you can see that while the "eggs"
setting carries the three expected values (one for each subproject plus
one extra), the "develop" setting contains just a single value, the one
injected by proj2, and the one that should be coming from proj1 is
missing. If I omit "src/proj2" from the extends option, then the
"develop" setting correctly contains just "src/proj1"...

Of course I tried hard to understand what's going, even walking into
buildout 1.5.2 code with pdb. I tried also with the latest development
version (the upcoming 1.6) as well as the github branch (IIUC it
derivates from 1.4), but all exhibit the same behaviour. The 1.6 code is
slightly different, and at first it seemed doing the right thing, but at
a closer look it really moved the problem from the "develop" setting
"eggs".

As far as I can tell, there is something strange happening in the
_update_section() function when the _open() function handles the
"extends" setting: at some point it "loses" the cognition that a certain
assignment is an expansion (tecnically, that the key is actually
"develop +", instead of "develop"), so the final "s1.update(s2)"
overrides it, instead of augmenting it...

Of course I may be doing the wrong thing or missing the obvious, and if
so I'll be happy if you can shed some light on me.

Thanks in advance for any help and sorry for the long post,

ciao, lele.

[1] http://artiemestieri.tn.it/~lele/test-buildout.tar.gz
-- 
nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.


From mal at egenix.com  Wed Aug 15 17:55:36 2012
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 15 Aug 2012 17:55:36 +0200
Subject: [Distutils] the 'wheel' binary package format
In-Reply-To: <CAG8k2+4YMgSDbjVsOY8J1qwkjoOdKLD28Gnp5RYDNMH8iesK5Q@mail.gmail.com>
References: <CAG8k2+4YMgSDbjVsOY8J1qwkjoOdKLD28Gnp5RYDNMH8iesK5Q@mail.gmail.com>
Message-ID: <502BC678.2040503@egenix.com>

You might also want to take a look at the "prebuilt" binary
format which we have been using for several years now, e.g.

http://www.egenix.com/products/python/mxBase/

The idea is a little different from what you describe, but works
well: we essentially take a snapshot of the package after it was
built and then put everything into a ZIP file.

As a result, you can pick up where distutils left off after the
build and continue the installation on the target machine.

The prebuilt files can also be installed and uninstalled with pip
if you reference the files directly.

The only feature missing is support in pip for finding and downloading
the right prebuilt archive from an index server. pip currently defaults
to downloading the Windows builds, because it checks for the "highest"
version available (for some meaning of high ;-)).

Which makes me think: would it be possible to make pip more clever
with respect to platform version strings ?

Here's are some examples of such a version strings as detected by
pip:

3.2.4.win32-py2.7.prebuilt
3.2.4.win-amd64-py2.7.prebuilt
3.2.4.linux-x86_64-py2.7_ucs4.prebuilt
3.2.4.linux-x86_64-py2.7_ucs2.prebuilt
3.2.4.linux-i686-py2.7_ucs4.prebuilt
3.2.4.linux-i686-py2.7_ucs2.prebuilt

The code for bdist_prebuilt is in the mxSetup.py that comes with
egenix-mx-base, in case you want to take a look.

Daniel Holth wrote:
> I got tired of waiting for lxml to compile over and over again, so I
> invented a binary packaging format called 'wheel' (of cheese) that
> uses Metadata 1.2 and .dist-info directories instead of .egg-info,
> patched pkg_resources.py to be able to load .dist-info directories,
> implemented "python setup.py bdist_wheel", and patched pip to be able
> to install .whl files.
> 
> The gist of the spec is that it is a zip file with the .whl extension
> containing the contents of 'purelib' for a distribution, plus a
> Name-1.0.dist-info/ directory with the metadata files, plus
> Name-1.0.data/subdir directories for scripts, platlib, packaging's
> "categories", ...
> 
> My specification so far is at
> https://docs.google.com/document/d/1mWPyvoeiqCrAy4UPNnvaz7Cgrqm4s_cfaTauAeJWABI/edit
> and an lxml compiled for linux-x86-64 is at
> https://docs.google.com/open?id=0BxHz5bC4iN5TN0VWTFNrZGtCbWs
> 
> http://bitbucket.org/dholth/distribute
> http://github.com/dholth/pip
> http://pypi.python.org/pypi/wheel
> 
> Perhaps it will be useful. The implementation is still pretty rough,
> for example it does not check the architecture while installing, but
> it could be a handy way to speed up repeated virtualenv builds.
> 
> Daniel Holth
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 15 2012)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2012-08-25: FrOSCon, St. Augustin, Germany ...             10 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/



From dholth at gmail.com  Wed Aug 15 18:05:35 2012
From: dholth at gmail.com (Daniel Holth)
Date: Wed, 15 Aug 2012 12:05:35 -0400
Subject: [Distutils] the 'wheel' binary package format
In-Reply-To: <502BC678.2040503@egenix.com>
References: <CAG8k2+4YMgSDbjVsOY8J1qwkjoOdKLD28Gnp5RYDNMH8iesK5Q@mail.gmail.com>
	<502BC678.2040503@egenix.com>
Message-ID: <CAG8k2+6FQ7DYOygt_YruC_UTjTLJ7881fkYRodbeRGeGUwyOkQ@mail.gmail.com>

On Wed, Aug 15, 2012 at 11:55 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> You might also want to take a look at the "prebuilt" binary
> format which we have been using for several years now, e.g.
>
> http://www.egenix.com/products/python/mxBase/
>
> The idea is a little different from what you describe, but works
> well: we essentially take a snapshot of the package after it was
> built and then put everything into a ZIP file.
>
> As a result, you can pick up where distutils left off after the
> build and continue the installation on the target machine.

Thanks, that is fascinating. Wheel goes a little further, and zips up
an installation of the package (with a particular set of installation
paths), and it doesn't include setup.py. This is important because I
want to be able to install into a Python that has no distutils at all.

> The prebuilt files can also be installed and uninstalled with pip
> if you reference the files directly.
>
> The only feature missing is support in pip for finding and downloading
> the right prebuilt archive from an index server. pip currently defaults
> to downloading the Windows builds, because it checks for the "highest"
> version available (for some meaning of high ;-)).
>
> Which makes me think: would it be possible to make pip more clever
> with respect to platform version strings ?

I do plan to implement this with some help from my friends, at least
as defined by PEP 425 (in progress;
http://hg.python.org/peps/file/tip/pep-0425.txt ). I think it will be
necessary to introduce the concept of picking the best package from a
set of candidates with the same version, instead of just picking the
highest version as pip does now.

> Here's are some examples of such a version strings as detected by
> pip:
>
> 3.2.4.win32-py2.7.prebuilt
> 3.2.4.win-amd64-py2.7.prebuilt
> 3.2.4.linux-x86_64-py2.7_ucs4.prebuilt
> 3.2.4.linux-x86_64-py2.7_ucs2.prebuilt
> 3.2.4.linux-i686-py2.7_ucs4.prebuilt
> 3.2.4.linux-i686-py2.7_ucs2.prebuilt
>
> The code for bdist_prebuilt is in the mxSetup.py that comes with
> egenix-mx-base, in case you want to take a look.

I will take a look.

Thanks,

Daniel

From mal at egenix.com  Thu Aug 16 15:16:13 2012
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 16 Aug 2012 15:16:13 +0200
Subject: [Distutils] the 'wheel' binary package format
In-Reply-To: <CAG8k2+6FQ7DYOygt_YruC_UTjTLJ7881fkYRodbeRGeGUwyOkQ@mail.gmail.com>
References: <CAG8k2+4YMgSDbjVsOY8J1qwkjoOdKLD28Gnp5RYDNMH8iesK5Q@mail.gmail.com>
	<502BC678.2040503@egenix.com>
	<CAG8k2+6FQ7DYOygt_YruC_UTjTLJ7881fkYRodbeRGeGUwyOkQ@mail.gmail.com>
Message-ID: <502CF29D.7010802@egenix.com>

Daniel Holth wrote:
> On Wed, Aug 15, 2012 at 11:55 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> You might also want to take a look at the "prebuilt" binary
>> format which we have been using for several years now, e.g.
>>
>> http://www.egenix.com/products/python/mxBase/
>>
>> The idea is a little different from what you describe, but works
>> well: we essentially take a snapshot of the package after it was
>> built and then put everything into a ZIP file.
>>
>> As a result, you can pick up where distutils left off after the
>> build and continue the installation on the target machine.
> 
> Thanks, that is fascinating. Wheel goes a little further, and zips up
> an installation of the package (with a particular set of installation
> paths), and it doesn't include setup.py. This is important because I
> want to be able to install into a Python that has no distutils at all.

Ok, that's a different set of requirements then. We wanted
to have most of the distutils commands and options working
in order to stay flexible during the actual installation process.

Since the prebuilt packages are also compatible to the standard
"python setup.py install" dance after you've unzipped them,
any installer using this approach will just work as well.

We've tested pip and both the install and uninstall commands
work fine out of the box as a result.

>> The prebuilt files can also be installed and uninstalled with pip
>> if you reference the files directly.
>>
>> The only feature missing is support in pip for finding and downloading
>> the right prebuilt archive from an index server. pip currently defaults
>> to downloading the Windows builds, because it checks for the "highest"
>> version available (for some meaning of high ;-)).
>>
>> Which makes me think: would it be possible to make pip more clever
>> with respect to platform version strings ?
> 
> I do plan to implement this with some help from my friends, at least
> as defined by PEP 425 (in progress;
> http://hg.python.org/peps/file/tip/pep-0425.txt ). I think it will be
> necessary to introduce the concept of picking the best package from a
> set of candidates with the same version, instead of just picking the
> highest version as pip does now.

Great. Please let me know when there's something available to
test. Since we currently only use the version strings for human
consumption, their are easy to change to whatever standard format
will get adopted.

The only requirements that we'd have for such a version tag format
(based on our experience with the prebuilt formats) is that it
includes:

 * a platform string with enough information to determine
   basic binary compatibility (ie. OS, architecture, perhaps
   also OS version depending on OS)
 * Python version, since the byte code changes with every release
 * Unicode variant; at least for those Python versions that need
   it, e.g. non-Windows builds, Python 2.x, 3.0-3.2.

There's an interesting problem we faced with pure-Python builds: on
Windows, many distutils commands store their internal path data in
the OS format, not in the standard distutils format (which uses
the Unix variant with os.sep == '/'). As a result, pure-Python builds
only work cross-platform with the prebuilt format if they are
created on a Unix host, since Windows works fine with the forward
slash os.sep at the API level. As a result, we had to put the
platform string on pure-Python builds created on Windows platforms.

>> Here's are some examples of such a version strings as detected by
>> pip:
>>
>> 3.2.4.win32-py2.7.prebuilt
>> 3.2.4.win-amd64-py2.7.prebuilt
>> 3.2.4.linux-x86_64-py2.7_ucs4.prebuilt
>> 3.2.4.linux-x86_64-py2.7_ucs2.prebuilt
>> 3.2.4.linux-i686-py2.7_ucs4.prebuilt
>> 3.2.4.linux-i686-py2.7_ucs2.prebuilt
>>
>> The code for bdist_prebuilt is in the mxSetup.py that comes with
>> egenix-mx-base, in case you want to take a look.
> 
> I will take a look.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 16 2012)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2012-08-25: FrOSCon, St. Augustin, Germany ...              9 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/



From qwcode at gmail.com  Fri Aug 17 02:21:16 2012
From: qwcode at gmail.com (Marcus Smith)
Date: Thu, 16 Aug 2012 17:21:16 -0700
Subject: [Distutils] py32, distutils, and __pycache__
Message-ID: <CAPYWazrZo041_6PKnZ1kJD=5c4iG_Jw8RTsO1uZhePTmA-39Yg@mail.gmail.com>

Hello:

I'm working on the new pip release and have a few questions revolving
around __pycache__, distutils, and distribute/setuptools
Hopefully some people here can increase my understanding on this.
btw, here's the specific pip issue this relates to:
https://github.com/pypa/pip/issues/638

I've read thru PEP3147, so I have a basic understanding of the various
import cases that it describes.

using py3.2.2, pip1.1 and distribute-0.6.27...

I want to confirm that all of the following are expected, normal and
actually ok?
I need to establish a baseline for the behaviors I should be working
against.

1) after installing distutils distributions or setuptools distributions, I
see inline *.pyc files (no __pycache__)

2) after importing one of the newly installed modules, I see the
__pycache__ folder appear with a new compiled file,
  but the old inline pyc file for the module still remains

3) when using --record with --single-version-externally-managed with a
setup.py using "setuptools",
  I'm finding that what get's used to generate the bytecode filenames is
`setuptools.command.install_lib._bytecode_filenames`.
  This was a little surprising given that
--single-version-externally-managed forces the use of
'distutils.command.install', so
  I was at first expecting
`distutils.command.install_lib._bytecode_filenames` to be used.
  I think `distutils.cmd.Command.get_sub_commands()` is responsible for the
use of `setuptools.command.install_lib` over
`distutils.command.install_lib` in this case.

4) Both `distutils.command.install_lib._bytecode_filenames` and
`setuptools.command.install_lib._bytecode_filenames` just generate inline
*.pyc[o] filenames.

I've seen this, http://bugs.python.org/issue11254, but I'm not clear on the
whole story.

Thanks in advance for any help,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120816/3546abd7/attachment.html>

From agroszer.ll at gmail.com  Fri Aug 17 08:32:38 2012
From: agroszer.ll at gmail.com (Adam GROSZER)
Date: Fri, 17 Aug 2012 08:32:38 +0200
Subject: [Distutils] Buildout 1.6 release tomorrow
In-Reply-To: <k0brnf$mj$1@dough.gmane.org>
References: <k0brnf$mj$1@dough.gmane.org>
Message-ID: <502DE586.4020607@gmail.com>

Hello,


uhh-ohh!!

1.6 seems to break on windows

See:
http://winbot.zope.org/builders/zope.location_py_265_32/builds/595/steps/buildout/logs/stdio

On 08/13/2012 11:31 PM, Alex Clark wrote:
> Hi,
>
>
> Please weigh in now if you have any serious concerns re: a Buildout 1.6
> release, as described here:
>
> - http://blog.aclark.net/2012/08/13/bootstrapping-a-buildout-1-6-release/
>
>
>
> Alex
>
>
>


-- 
Best regards,
  Adam GROSZER
--
Quote of the day:
Don't tell any big lies today. Small ones can be just as effective.

From matthew.churcher at realvnc.com  Fri Aug 17 13:08:25 2012
From: matthew.churcher at realvnc.com (Matthew Churcher)
Date: Fri, 17 Aug 2012 11:08:25 +0000 (GMT+00:00)
Subject: [Distutils] Buildout 1.6.0
In-Reply-To: <1441607678.4776.1345201587632.JavaMail.root@realvnc.com>
Message-ID: <941616202.4802.1345201705065.JavaMail.root@realvnc.com>

Hi all,

We are experiencing difficulties here on multiple windows machines with buildout 1.6.0 that we did not have with buildout 1.5.2. This is with multiple windows and python versions. Linux machines are not affected.

When calling bin\buildout.exe the following error occurs:

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
  File "c:\svn\remoteaccess\eggs\zc.buildout-1.6.0-py2.7.egg\zc\buildout\buildout.py", line 1848, in main
    getattr(buildout, command)(args)
  File "c:\svn\remoteaccess\eggs\zc.buildout-1.6.0-py2.7.egg\zc\buildout\buildout.py", line 480, in install
    installed_develop_eggs = self._develop()
  File "c:\svn\remoteaccess\eggs\zc.buildout-1.6.0-py2.7.egg\zc\buildout\buildout.py", line 720, in _develop
    zc.buildout.easy_install.develop(setup, dest)
  File "c:\svn\remoteaccess\eggs\zc.buildout-1.6.0-py2.7.egg\zc\buildout\easy_install.py", line 1186, in develop
    subprocess.check_call([_safe_arg(executable)] + args)
  File "c:\Python27\lib\subprocess.py", line 499, in check_call
    retcode = call(*popenargs, **kwargs)
  File "c:\Python27\lib\subprocess.py", line 486, in call
    return Popen(*popenargs, **kwargs).wait()
  File "c:\Python27\lib\subprocess.py", line 672, in __init__
    errread, errwrite)
  File "c:\Python27\lib\subprocess.py", line 882, in _execute_child
    startupinfo)
WindowsError: [Error 2] The system cannot find the file specified

We are currently working around this by pinning bootstrap.py to version 1.5.2. 'python bootstrap.py -v "1.5.2"'.

I can't find any references to this issue online, so was wondering if it had reported and if you are aware of the issue?

Thanks in advanced,
Matt

From aclark at aclark.net  Fri Aug 17 15:55:28 2012
From: aclark at aclark.net (Alex Clark)
Date: Fri, 17 Aug 2012 09:55:28 -0400
Subject: [Distutils] Buildout 1.6 release tomorrow
In-Reply-To: <502DE586.4020607@gmail.com>
References: <k0brnf$mj$1@dough.gmane.org> <502DE586.4020607@gmail.com>
Message-ID: <k0ligf$g63$1@ger.gmane.org>

On 8/17/12 2:32 AM, Adam GROSZER wrote:
> Hello,
>
>
> uhh-ohh!!
>
> 1.6 seems to break on windows
>
> See:
> http://winbot.zope.org/builders/zope.location_py_265_32/builds/595/steps/buildout/logs/stdio


Thanks, we'll get a 1.6.1 out ASAP, any idea what the problem is? I had 
iElectric run the tests on Windows?


Alex


>
>
> On 08/13/2012 11:31 PM, Alex Clark wrote:
>> Hi,
>>
>>
>> Please weigh in now if you have any serious concerns re: a Buildout 1.6
>> release, as described here:
>>
>> - http://blog.aclark.net/2012/08/13/bootstrapping-a-buildout-1-6-release/
>>
>>
>>
>> Alex
>>
>>
>>
>
>


-- 
Alex Clark ? http://pythonpackages.com/ONE_CLICK


From aclark at aclark.net  Fri Aug 17 15:56:56 2012
From: aclark at aclark.net (Alex Clark)
Date: Fri, 17 Aug 2012 09:56:56 -0400
Subject: [Distutils] Buildout 1.6.0
In-Reply-To: <941616202.4802.1345201705065.JavaMail.root@realvnc.com>
References: <1441607678.4776.1345201587632.JavaMail.root@realvnc.com>
	<941616202.4802.1345201705065.JavaMail.root@realvnc.com>
Message-ID: <k0lij7$g63$2@ger.gmane.org>

On 8/17/12 7:08 AM, Matthew Churcher wrote:
> Hi all,
>
> We are experiencing difficulties here on multiple windows machines with buildout 1.6.0 that we did not have with buildout 1.5.2. This is with multiple windows and python versions. Linux machines are not affected.
>
> When calling bin\buildout.exe the following error occurs:
>
> An internal error occurred due to a bug in either zc.buildout or in a
> recipe being used:
> Traceback (most recent call last):
>    File "c:\svn\remoteaccess\eggs\zc.buildout-1.6.0-py2.7.egg\zc\buildout\buildout.py", line 1848, in main
>      getattr(buildout, command)(args)
>    File "c:\svn\remoteaccess\eggs\zc.buildout-1.6.0-py2.7.egg\zc\buildout\buildout.py", line 480, in install
>      installed_develop_eggs = self._develop()
>    File "c:\svn\remoteaccess\eggs\zc.buildout-1.6.0-py2.7.egg\zc\buildout\buildout.py", line 720, in _develop
>      zc.buildout.easy_install.develop(setup, dest)
>    File "c:\svn\remoteaccess\eggs\zc.buildout-1.6.0-py2.7.egg\zc\buildout\easy_install.py", line 1186, in develop
>      subprocess.check_call([_safe_arg(executable)] + args)
>    File "c:\Python27\lib\subprocess.py", line 499, in check_call
>      retcode = call(*popenargs, **kwargs)
>    File "c:\Python27\lib\subprocess.py", line 486, in call
>      return Popen(*popenargs, **kwargs).wait()
>    File "c:\Python27\lib\subprocess.py", line 672, in __init__
>      errread, errwrite)
>    File "c:\Python27\lib\subprocess.py", line 882, in _execute_child
>      startupinfo)
> WindowsError: [Error 2] The system cannot find the file specified
>
> We are currently working around this by pinning bootstrap.py to version 1.5.2. 'python bootstrap.py -v "1.5.2"'.
>
> I can't find any references to this issue online, so was wondering if it had reported and if you are aware of the issue?


Someone else just reported it on this list, we'll get a 1.6.1 out ASAP. 
If you have a fix, please let us know.


Alex




>
> Thanks in advanced,
> Matt
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>


-- 
Alex Clark ? http://pythonpackages.com/ONE_CLICK


From chris at kateandchris.net  Fri Aug 17 18:15:39 2012
From: chris at kateandchris.net (Chris Lambacher)
Date: Fri, 17 Aug 2012 12:15:39 -0400
Subject: [Distutils] Buildout 1.6.0
In-Reply-To: <k0lij7$g63$2@ger.gmane.org>
References: <1441607678.4776.1345201587632.JavaMail.root@realvnc.com>
	<941616202.4802.1345201705065.JavaMail.root@realvnc.com>
	<k0lij7$g63$2@ger.gmane.org>
Message-ID: <CAAXXHg+XtoYif7drB8hUY3e4YFcwDhjENcsMWeZuwLW3fBnruQ@mail.gmail.com>

Hi Alex,

I am suspicious of the _safe_arg being used on that line. It adds quotes
around each argument but you are not passing the shell=True arg to
subprocess.check_call so nothing is processing those quotes effectively
setting the executable to "C:\\python27\python.exe" including the quotes.
That would be consistent with the error you are getting.

I haven't been able to figure out how to use the tests/get it to pick up
the version out of my checked out source tree so I am having difficulty in
verifying my theory. I tried asking on #buildout but did not get any
response.

-Chris

On Fri, Aug 17, 2012 at 9:56 AM, Alex Clark <aclark at aclark.net> wrote:

> On 8/17/12 7:08 AM, Matthew Churcher wrote:
>
>> Hi all,
>>
>> We are experiencing difficulties here on multiple windows machines with
>> buildout 1.6.0 that we did not have with buildout 1.5.2. This is with
>> multiple windows and python versions. Linux machines are not affected.
>>
>> When calling bin\buildout.exe the following error occurs:
>>
>> An internal error occurred due to a bug in either zc.buildout or in a
>> recipe being used:
>> Traceback (most recent call last):
>>    File "c:\svn\remoteaccess\eggs\zc.**buildout-1.6.0-py2.7.egg\zc\**buildout\buildout.py",
>> line 1848, in main
>>      getattr(buildout, command)(args)
>>    File "c:\svn\remoteaccess\eggs\zc.**buildout-1.6.0-py2.7.egg\zc\**buildout\buildout.py",
>> line 480, in install
>>      installed_develop_eggs = self._develop()
>>    File "c:\svn\remoteaccess\eggs\zc.**buildout-1.6.0-py2.7.egg\zc\**buildout\buildout.py",
>> line 720, in _develop
>>      zc.buildout.easy_install.**develop(setup, dest)
>>    File "c:\svn\remoteaccess\eggs\zc.**buildout-1.6.0-py2.7.egg\zc\**buildout\easy_install.py",
>> line 1186, in develop
>>      subprocess.check_call([_safe_**arg(executable)] + args)
>>    File "c:\Python27\lib\subprocess.**py", line 499, in check_call
>>      retcode = call(*popenargs, **kwargs)
>>    File "c:\Python27\lib\subprocess.**py", line 486, in call
>>      return Popen(*popenargs, **kwargs).wait()
>>    File "c:\Python27\lib\subprocess.**py", line 672, in __init__
>>      errread, errwrite)
>>    File "c:\Python27\lib\subprocess.**py", line 882, in _execute_child
>>      startupinfo)
>> WindowsError: [Error 2] The system cannot find the file specified
>>
>> We are currently working around this by pinning bootstrap.py to version
>> 1.5.2. 'python bootstrap.py -v "1.5.2"'.
>>
>> I can't find any references to this issue online, so was wondering if it
>> had reported and if you are aware of the issue?
>>
>
>
> Someone else just reported it on this list, we'll get a 1.6.1 out ASAP. If
> you have a fix, please let us know.
>
>
> Alex
>
>
>
>
>
>
>> Thanks in advanced,
>> Matt
>> ______________________________**_________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> http://mail.python.org/**mailman/listinfo/distutils-sig<http://mail.python.org/mailman/listinfo/distutils-sig>
>>
>>
>
> --
> Alex Clark ? http://pythonpackages.com/ONE_**CLICK<http://pythonpackages.com/ONE_CLICK>
>
>
> ______________________________**_________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/**mailman/listinfo/distutils-sig<http://mail.python.org/mailman/listinfo/distutils-sig>
>



-- 
Christopher Lambacher
chris at kateandchris.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120817/00643b46/attachment.html>

From aclark at aclark.net  Fri Aug 17 20:13:31 2012
From: aclark at aclark.net (Alex Clark)
Date: Fri, 17 Aug 2012 14:13:31 -0400
Subject: [Distutils] Buildout 1.6.0
In-Reply-To: <CAAXXHg+XtoYif7drB8hUY3e4YFcwDhjENcsMWeZuwLW3fBnruQ@mail.gmail.com>
References: <1441607678.4776.1345201587632.JavaMail.root@realvnc.com>
	<941616202.4802.1345201705065.JavaMail.root@realvnc.com>
	<k0lij7$g63$2@ger.gmane.org>
	<CAAXXHg+XtoYif7drB8hUY3e4YFcwDhjENcsMWeZuwLW3fBnruQ@mail.gmail.com>
Message-ID: <k0m1kc$kl5$1@ger.gmane.org>

Hi Chris,

On 8/17/12 12:15 PM, Chris Lambacher wrote:
> Hi Alex,
>
> I am suspicious of the _safe_arg being used on that line. It adds quotes
> around each argument but you are not passing the shell=True arg to
> subprocess.check_call so nothing is processing those quotes effectively
> setting the executable to "C:\\python27\python.exe" including the
> quotes. That would be consistent with the error you are getting.


Thanks for the feedback! I think Domen Ko?ar (iElectric) is working on it.

>
> I haven't been able to figure out how to use the tests/get it to pick up
> the version out of my checked out source tree so I am having difficulty
> in verifying my theory. I tried asking on #buildout but did not get any
> response.


Does this help at all? 
https://github.com/buildout/buildout/blob/1.6.x/DEVELOPERS.txt



Alex




>
> -Chris
>
> On Fri, Aug 17, 2012 at 9:56 AM, Alex Clark <aclark at aclark.net
> <mailto:aclark at aclark.net>> wrote:
>
>     On 8/17/12 7:08 AM, Matthew Churcher wrote:
>
>         Hi all,
>
>         We are experiencing difficulties here on multiple windows
>         machines with buildout 1.6.0 that we did not have with buildout
>         1.5.2. This is with multiple windows and python versions. Linux
>         machines are not affected.
>
>         When calling bin\buildout.exe the following error occurs:
>
>         An internal error occurred due to a bug in either zc.buildout or
>         in a
>         recipe being used:
>         Traceback (most recent call last):
>             File
>         "c:\svn\remoteaccess\eggs\zc.__buildout-1.6.0-py2.7.egg\zc\__buildout\buildout.py",
>         line 1848, in main
>               getattr(buildout, command)(args)
>             File
>         "c:\svn\remoteaccess\eggs\zc.__buildout-1.6.0-py2.7.egg\zc\__buildout\buildout.py",
>         line 480, in install
>               installed_develop_eggs = self._develop()
>             File
>         "c:\svn\remoteaccess\eggs\zc.__buildout-1.6.0-py2.7.egg\zc\__buildout\buildout.py",
>         line 720, in _develop
>               zc.buildout.easy_install.__develop(setup, dest)
>             File
>         "c:\svn\remoteaccess\eggs\zc.__buildout-1.6.0-py2.7.egg\zc\__buildout\easy_install.py",
>         line 1186, in develop
>               subprocess.check_call([_safe___arg(executable)] + args)
>             File "c:\Python27\lib\subprocess.__py", line 499, in check_call
>               retcode = call(*popenargs, **kwargs)
>             File "c:\Python27\lib\subprocess.__py", line 486, in call
>               return Popen(*popenargs, **kwargs).wait()
>             File "c:\Python27\lib\subprocess.__py", line 672, in __init__
>               errread, errwrite)
>             File "c:\Python27\lib\subprocess.__py", line 882, in
>         _execute_child
>               startupinfo)
>         WindowsError: [Error 2] The system cannot find the file specified
>
>         We are currently working around this by pinning bootstrap.py to
>         version 1.5.2. 'python bootstrap.py -v "1.5.2"'.
>
>         I can't find any references to this issue online, so was
>         wondering if it had reported and if you are aware of the issue?
>
>
>
>     Someone else just reported it on this list, we'll get a 1.6.1 out
>     ASAP. If you have a fix, please let us know.
>
>
>     Alex
>
>
>
>
>
>
>         Thanks in advanced,
>         Matt
>         _________________________________________________
>         Distutils-SIG maillist  - Distutils-SIG at python.org
>         <mailto:Distutils-SIG at python.org>
>         http://mail.python.org/__mailman/listinfo/distutils-sig
>         <http://mail.python.org/mailman/listinfo/distutils-sig>
>
>
>
>     --
>     Alex Clark ? http://pythonpackages.com/ONE___CLICK
>     <http://pythonpackages.com/ONE_CLICK>
>
>
>     _________________________________________________
>     Distutils-SIG maillist  - Distutils-SIG at python.org
>     <mailto:Distutils-SIG at python.org>
>     http://mail.python.org/__mailman/listinfo/distutils-sig
>     <http://mail.python.org/mailman/listinfo/distutils-sig>
>
>
>
>
> --
> Christopher Lambacher
> chris at kateandchris.net <mailto:chris at kateandchris.net>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>


-- 
Alex Clark ? http://pythonpackages.com/ONE_CLICK


From shimizukawa at gmail.com  Sat Aug 18 08:32:12 2012
From: shimizukawa at gmail.com (Takayuki Shimizukawa)
Date: Sat, 18 Aug 2012 15:32:12 +0900
Subject: [Distutils] Buildout 1.6.0 : can't init new environment (I don't
	need bootstrap package)
Message-ID: <CADstH-7U33MvBjeJj6_n3sH2ANppoZc14PX4N1eD5umaiMVqXw@mail.gmail.com>

Hi,

I'm trying to create new buildout environment with zc.buildout-1.6.0, but...::

   D:> python bootstrap.py -d init
   Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.28.tar.gz
   -snip-
   c:\users\taka\appdata\local\temp\tmpb0blmq\distribute-0.6.28-py2.7.egg
   Creating 'D:\\bo16\\buildout.cfg'.
   Creating directory 'D:\\bo16\\bin'.
   Creating directory 'D:\\bo16\\parts'.
   Creating directory 'D:\\bo16\\develop-eggs'.
   Generated script 'D:\\bo16\\bin\\buildout'.
   Installing py.
   Getting distribution for 'pycrypto'.
   warning: GMP or MPIR library not found; Not building
Crypto.PublicKey._fastmath.
   error: Setup script exited with error: Unable to find vcvarsall.bat
   An error occurred when trying to install pycrypto 2.6. Look above
this message for any errors that were output by easy_install.
   While:
     Installing py.
     Getting distribution for 'pycrypto'.
   Error: Couldn't install: pycrypto 2.6


   D:> cat buildout.cfg
   [buildout]
   parts = py

   [py]
   recipe = zc.recipe.egg
   interpreter = py
   eggs =
     bootstrap

Why `bootstrap` package was required?

Ah, bootstrap.py invoke ``zc.buildout.buildout.main(['init',
'bootstrap'])`` (before buildout 1.6.0) but buildout-1.6.0 introduce
init command sub parameter to accepts distribution requirements as
like as ``python bootstrap.py init BeautifulSoup``.

Does bootstrap.py require 'bootstrap' argument?
https://github.com/buildout/buildout/blob/1.6.x/bootstrap/bootstrap.py#L156

-- 
Takayuki SHIMIZUKAWA

From domen at dev.si  Sat Aug 18 20:42:08 2012
From: domen at dev.si (Domen =?utf-8?b?S2/FvmFy?=)
Date: Sat, 18 Aug 2012 18:42:08 +0000 (UTC)
Subject: [Distutils]
	=?utf-8?q?Buildout_1=2E6=2E0_=3A_can=27t_init_new_env?=
	=?utf-8?q?ironment_=28I_don=27t=09need_bootstrap_package=29?=
References: <CADstH-7U33MvBjeJj6_n3sH2ANppoZc14PX4N1eD5umaiMVqXw@mail.gmail.com>
Message-ID: <loom.20120818T204041-179@post.gmane.org>

Fixed: 
https://github.com/buildout/buildout/commit/88eb20328fc0fcdec3a7fa555393573e6323
15a8

Will be soonish release as 1.6.1



From domen at dev.si  Sat Aug 18 20:45:19 2012
From: domen at dev.si (Domen =?utf-8?b?S2/FvmFy?=)
Date: Sat, 18 Aug 2012 18:45:19 +0000 (UTC)
Subject: [Distutils] Struggling with a modular buildout configuration
References: <87lihgp6gn.fsf@metapensiero.it>
Message-ID: <loom.20120818T204418-92@post.gmane.org>

Hi Lele,

can you provide an example that would illustrate the problem? The file you 
submitted fails because projects do not include setup.py. I would advise to use 
zc.buildout 1.6.0 and see if issue persists.


From domen at dev.si  Sat Aug 18 20:47:17 2012
From: domen at dev.si (Domen =?utf-8?b?S2/FvmFy?=)
Date: Sat, 18 Aug 2012 18:47:17 +0000 (UTC)
Subject: [Distutils] Buildout 1.6.0
References: <1441607678.4776.1345201587632.JavaMail.root@realvnc.com>
	<941616202.4802.1345201705065.JavaMail.root@realvnc.com>
	<k0lij7$g63$2@ger.gmane.org>
	<CAAXXHg+XtoYif7drB8hUY3e4YFcwDhjENcsMWeZuwLW3fBnruQ@mail.gmail.com>
Message-ID: <loom.20120818T204548-796@post.gmane.org>

Hi Chris,

I've been fighting with zc.buildout tests for past 2 days.
I have fixed Python 2.4 compatibility and struggled with
windows tests. If you manage to come up with 
the patch, please submit it to https://github.com/buildout/buildout

Cheers, Domen


From aclark at aclark.net  Sun Aug 19 03:13:23 2012
From: aclark at aclark.net (Alex Clark)
Date: Sat, 18 Aug 2012 21:13:23 -0400
Subject: [Distutils] Buildout 1.6.1 released
Message-ID: <k0peji$shv$1@ger.gmane.org>

Hi,

Domen Ko?ar has fixed some regressions so we cut a 1.6.1:

- http://pypi.python.org/pypi/zc.buildout/1.6.1#id9

Chris Lambacher has been working on the remaining Windows issues and 
had this to say in #buildout:

    "my assessement is that pretty much everywhere a safe string is 
used prior to going into Popen / subprocess.* that is  wrong. The 
_safe_arg was introduced when os.spawnle was being used and the 
parameters(but not the executable) need to be quoted. subprocess 
handles that automatically if you give it an arg list (which is what is 
happening pretty much everywhere subprocess is being used)."

If anyone with Windows experience could confirm and turn the above info 
into a patch, please let us know (e.g. via pull request on GitHub)




Alex




-- 
Alex Clark ? http://pythonpackages.com



From agroszer at gmail.com  Sun Aug 19 09:50:26 2012
From: agroszer at gmail.com (Adam Groszer)
Date: Sun, 19 Aug 2012 09:50:26 +0200
Subject: [Distutils] Buildout 1.6.0
In-Reply-To: <loom.20120818T204548-796@post.gmane.org>
References: <1441607678.4776.1345201587632.JavaMail.root@realvnc.com>
	<941616202.4802.1345201705065.JavaMail.root@realvnc.com>
	<k0lij7$g63$2@ger.gmane.org>
	<CAAXXHg+XtoYif7drB8hUY3e4YFcwDhjENcsMWeZuwLW3fBnruQ@mail.gmail.com>
	<loom.20120818T204548-796@post.gmane.org>
Message-ID: <CAJk=hQaZ0ubi8yrKfmm4EHbBW-5S=0m_LrRVAXVdLg2EmqZAQA@mail.gmail.com>

Hello,

Are you able to run the tests?

On Sat, Aug 18, 2012 at 8:47 PM, Domen Ko?ar <domen at dev.si> wrote:
> Hi Chris,
>
> I've been fighting with zc.buildout tests for past 2 days.
> I have fixed Python 2.4 compatibility and struggled with
> windows tests. If you manage to come up with
> the patch, please submit it to https://github.com/buildout/buildout
>
> Cheers, Domen
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

From shimizukawa at gmail.com  Sun Aug 19 11:13:28 2012
From: shimizukawa at gmail.com (Takayuki Shimizukawa)
Date: Sun, 19 Aug 2012 18:13:28 +0900
Subject: [Distutils] Buildout 1.6.0 : can't init new environment (I
 don't need bootstrap package)
In-Reply-To: <loom.20120818T204041-179@post.gmane.org>
References: <CADstH-7U33MvBjeJj6_n3sH2ANppoZc14PX4N1eD5umaiMVqXw@mail.gmail.com>
	<loom.20120818T204041-179@post.gmane.org>
Message-ID: <CADstH-4c+qJ5Q22bxxjtTuacQs2SKthtbM1PK2eP-FuvrWFtiA@mail.gmail.com>

Hi Domen,

2012/8/19 Domen Ko?ar <domen at dev.si>:
> Fixed:
> https://github.com/buildout/buildout/commit/88eb20328fc0fcdec3a7fa555393573e6323
> 15a8
>
> Will be soonish release as 1.6.1

I confirmed. Thanks!

-- 
Takayuki SHIMIZUKAWA

From shimizukawa at gmail.com  Sun Aug 19 11:45:21 2012
From: shimizukawa at gmail.com (Takayuki Shimizukawa)
Date: Sun, 19 Aug 2012 18:45:21 +0900
Subject: [Distutils] Buildout 1.6.1 released
In-Reply-To: <k0peji$shv$1@ger.gmane.org>
References: <k0peji$shv$1@ger.gmane.org>
Message-ID: <CADstH-53jmVVpMmDA_-i2ZCWmBjXGHJMAdtzHWeEXs+ZD+MeSA@mail.gmail.com>

Hi Alex, Domen,

Thank you to fix and release quickly!

I checked the zc.buildout-1.6.1 and maybe some issues.
And I filed report it;

- documentation issue: https://github.com/buildout/buildout/issues/8
- old options issue: https://github.com/buildout/buildout/issues/9

Regards,
--
Takayuki SHIMIZUKAWA

2012/8/19 Alex Clark <aclark at aclark.net>:
> Hi,
>
> Domen Ko?ar has fixed some regressions so we cut a 1.6.1:
>
> - http://pypi.python.org/pypi/zc.buildout/1.6.1#id9
>
> Chris Lambacher has been working on the remaining Windows issues and had
> this to say in #buildout:
>
>    "my assessement is that pretty much everywhere a safe string is used
> prior to going into Popen / subprocess.* that is  wrong. The _safe_arg was
> introduced when os.spawnle was being used and the parameters(but not the
> executable) need to be quoted. subprocess handles that automatically if you
> give it an arg list (which is what is happening pretty much everywhere
> subprocess is being used)."
>
> If anyone with Windows experience could confirm and turn the above info into
> a patch, please let us know (e.g. via pull request on GitHub)
>
>
>
>
> Alex
>
>
>
>
> --
> Alex Clark ? http://pythonpackages.com
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

From lele at metapensiero.it  Sun Aug 19 15:01:44 2012
From: lele at metapensiero.it (Lele Gaifax)
Date: Sun, 19 Aug 2012 15:01:44 +0200
Subject: [Distutils] Struggling with a modular buildout configuration
References: <87lihgp6gn.fsf@metapensiero.it>
	<loom.20120818T204418-92@post.gmane.org>
Message-ID: <87mx1rghmv.fsf@metapensiero.it>

> can you provide an example that would illustrate the problem? The file
> you submitted fails because projects do not include setup.py. I would
> advise to use zc.buildout 1.6.0 and see if issue persists.

Sure, I added minimalistic setup.py to both subprojects:

  http://artiemestieri.tn.it/~lele/test-buildout-2.tar.gz

As is, executing a buildout (btw, using latest 1.6.1 now), I get:

    $ buildout
    Creating directory '/tmp/test-zcb/bin'.
    Creating directory '/tmp/test-zcb/parts'.
    Creating directory '/tmp/test-zcb/develop-eggs'.
    Develop: '/tmp/test-zcb/src/proj2'
    Installing extra-parts-from-proj2.

Note it does not even mention anything from proj1, even if it is surely
loading its configuration snippets:

    $ buildout annotate | grep proj1
    proj1
    +=  /tmp/test-zcb/src/proj1/devel.cfg
    +=  /tmp/test-zcb/src/proj1/base.cfg

and it does not install the [python] recipe neither...

If I comment out the last line in the top level projects.cfg, the one
that includes the proj2/devel.cfg, I get:

    $ buildout
    Develop: '/tmp/test-zcb/src/proj1'
    Running uninstall recipe.
    Installing python.
    Generated interpreter '/tmp/test-zcb/bin/python'.

This time it installed the [python] recipe, and effectively

    $ bin/python -m project1
    Hello from project1

with the extra package too:

    $ bin/python -c "import faker; print faker.__version__"
    0.0.4

So, it really seems that loading the projX extension clobbers the
previous settings, but I cannot see what I'm doing wrong.

Thanks a lot for your time, and for any enlightenment :-)
ciao, lele.

PS: I won't be able to follow the group for the next two weeks as I'm
taking a long awaited vacation.


From setuptools at bugs.python.org  Sun Aug 19 23:10:01 2012
From: setuptools at bugs.python.org (Reuben Thomas)
Date: Sun, 19 Aug 2012 21:10:01 +0000
Subject: [Distutils] [issue144] Improve per-user installation instructions
Message-ID: <1345410601.07.0.333105890177.issue144@psf.upfronthosting.co.za>


New submission from Reuben Thomas:

The instructions for non-root use of EasyInstall appear to be out of date; specifically, they don't seem to take PEP 370 into account.

My suggestion is that you replace the section called 'Mac OS X "User"
Installation' with a section called "Home directory installation" and
explain the PEP 370 method, which was implemented in Python 2.6, and
works on all OSes. With a ~/.pydistutils.cfg like the following:

[install]
install_lib = ~/.local/lib/python$py_version_short/site-packages
install_scripts = ~/.local/bin

You can install packages to PEP 370 paths, including scripts, and you
are using the same paths as if you use python setup.py install
--prefix=$HOME/.local.

You can then also remove the "Virtual python" section. Of course, some
users may still want to use Virtual Python with easy_install, but they
don't need special documentation to do so; they can just use the
Virtual Python documentation.

----------
messages: 693
nosy: rrt
priority: feature
status: unread
title: Improve per-user installation instructions

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

From chris at simplistix.co.uk  Tue Aug 21 22:30:53 2012
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 21 Aug 2012 21:30:53 +0100
Subject: [Distutils] buildout 1.6 on windows
Message-ID: <5033EFFD.1070608@simplistix.co.uk>

Hi All,

I'm pretty dismayed at the lack of QA that was done on the 1.6 release 
before it was released.

I'm annoyed that the "latest" release of Buildout is completely hosed on 
Windows, and so I now see all my CI slowly turning red:

http://jenkins.simplistix.co.uk/

When are we going to see a fixed release? Or do I really have to do and 
pin all my buildouts to 1.5.x?!

Chris

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

From jim at zope.com  Tue Aug 21 23:15:08 2012
From: jim at zope.com (Jim Fulton)
Date: Tue, 21 Aug 2012 17:15:08 -0400
Subject: [Distutils] buildout 1.6 on windows
In-Reply-To: <5033EFFD.1070608@simplistix.co.uk>
References: <5033EFFD.1070608@simplistix.co.uk>
Message-ID: <CAPDm-FjgUGoevnvbPR64ddqOc1_T4Ji_a9LHAi0W+=rWWZXG1w@mail.gmail.com>

On Tue, Aug 21, 2012 at 4:30 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> Hi All,
>
> I'm pretty dismayed at the lack of QA that was done on the 1.6 release
> before it was released.
>
> I'm annoyed that the "latest" release of Buildout is completely hosed on
> Windows, and so I now see all my CI slowly turning red:
>
> http://jenkins.simplistix.co.uk/
>
> When are we going to see a fixed release? Or do I really have to do and pin
> all my buildouts to 1.5.x?!

Perhaps I should re-release 1.5.2 as 1.6.2 until the windows support in 1.6
gets sorted out.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm

From aclark at aclark.net  Wed Aug 22 02:15:57 2012
From: aclark at aclark.net (Alex Clark)
Date: Tue, 21 Aug 2012 20:15:57 -0400
Subject: [Distutils] buildout 1.6 on windows
References: <5033EFFD.1070608@simplistix.co.uk>
	<CAPDm-FjgUGoevnvbPR64ddqOc1_T4Ji_a9LHAi0W+=rWWZXG1w@mail.gmail.com>
Message-ID: <k118bs$fvp$1@ger.gmane.org>

On 2012-08-21 21:15:08 +0000, Jim Fulton said:

> On Tue, Aug 21, 2012 at 4:30 PM, Chris Withers 
> <chris at simplistix.co.uk> wrote:
>> Hi All,
>> 
>> I'm pretty dismayed at the lack of QA that was done on the 1.6 release
>> before it was released.
>> 
>> I'm annoyed that the "latest" release of Buildout is completely hosed on
>> Windows, and so I now see all my CI slowly turning red:
>> 
>> http://jenkins.simplistix.co.uk/
>> 
>> When are we going to see a fixed release? Or do I really have to do and pin
>> all my buildouts to 1.5.x?!
> 
> Perhaps I should re-release 1.5.2 as 1.6.2 until the windows support in 1.6
> gets sorted out.


OOPS, answered this on buildout-dev already, sorry (missed the 
cross-post, and Unison seems to have missed it too). I'll release a 
1.6.2 containing Windows fixes sometime tonight.


> 
> Jim


-- 
Alex Clark ? http://pythonpackages.com



From dholth at gmail.com  Wed Aug 22 04:52:04 2012
From: dholth at gmail.com (Daniel Holth)
Date: Tue, 21 Aug 2012 22:52:04 -0400
Subject: [Distutils] wheel file signatures scheme
Message-ID: <CAG8k2+64-5ojP6S86kWD1w9+w5iOVmH4HwG41gKHLb5DmWRp5g@mail.gmail.com>

I've made what I think is exciting progress on the digital signatures
design for wheel (updated built/binary packages for Python; intended
to replace egg). The insight is that we can overload the "extras"
syntax as a convenient way to mention the public key we expect:

package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]

This line in a pip-style requires.txt specifies that we want to
install package, the normal optional dependency "extra" and that we
expect it to have a valid signature made with the mentioned ed25519
public key.

Distribute your application, assemble its requirements in this format,
sign that file, and Bob's your uncle -- your users can install from
that file and know that the requirements they download have the same
publishers as the packages you developed with. This is far more
powerful than a file hash because it is valid for more than one
version of the package.

For backwards compatibility, packages can say they provide the extra
ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA (adding no
dependencies) and easy_install should parse and ignore it, installing
from an unsigned egg or source distribution because it doesn't know
about wheels.

bdist_wheel will be updated to always sign the wheels it generates if
possible, making up a new signing key if one is not stored on the
building machine. That way signed wheels will be commonplace, and the
remaining problem is simply to decide which signing keys you would
like to trust.

wheel now includes a command line tool `wheel sign wheelfile.whl` that
adds a digital signature to a wheel file.

http://wheel.readthedocs.org/en/latest/index.html#signed-wheel-files

From chris at simplistix.co.uk  Wed Aug 22 07:30:41 2012
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 22 Aug 2012 06:30:41 +0100
Subject: [Distutils] buildout 1.6 on windows
In-Reply-To: <k11aq8$rl$1@ger.gmane.org>
References: <5033EFFD.1070608@simplistix.co.uk> <k11aq8$rl$1@ger.gmane.org>
Message-ID: <50346E81.9080602@simplistix.co.uk>

On 22/08/2012 01:57, Alex Clark wrote:
> On 2012-08-21 20:30:53 +0000, Chris Withers said:
>
>> Hi All,
>>
>> I'm pretty dismayed at the lack of QA that was done on the 1.6 release
>> before it was released.
>>
>> I'm annoyed that the "latest" release of Buildout is completely hosed
>> on Windows, and so I now see all my CI slowly turning red:
>>
>> http://jenkins.simplistix.co.uk/
>>
>> When are we going to see a fixed release? Or do I really have to do
>> and pin all my buildouts to 1.5.x?!
>
>
> Fixed, sorry about that.

Doesn't look like it...

http://jenkins.simplistix.co.uk/job/testfixtures-buildout/124/PYTHON=2.7,label=windows/console

Chris

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

From chris at simplistix.co.uk  Wed Aug 22 08:30:12 2012
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 22 Aug 2012 07:30:12 +0100
Subject: [Distutils] buildout 1.6 on windows
In-Reply-To: <CAKAV2_nv2h3+gumvnDB4srMfnF0VB7XMRa0bU=mOyQrrMJ8N5w@mail.gmail.com>
References: <5033EFFD.1070608@simplistix.co.uk>
	<CAPDm-FjgUGoevnvbPR64ddqOc1_T4Ji_a9LHAi0W+=rWWZXG1w@mail.gmail.com>
	<k112nl$98v$1@ger.gmane.org> <50340FDA.40408@simplistix.co.uk>
	<CAKAV2_nv2h3+gumvnDB4srMfnF0VB7XMRa0bU=mOyQrrMJ8N5w@mail.gmail.com>
Message-ID: <50347C74.40203@simplistix.co.uk>

Hi All,

At Alex's request:

On 21/08/2012 23:56, Alex Clark wrote:
> On Tue, Aug 21, 2012 at 6:46 PM, Chris Withers <chris at simplistix.co.uk
> <mailto:chris at simplistix.co.uk>> wrote:
>
>     Alex,
>
>     On 21/08/2012 23:39, Alex Clark wrote:
>
>             Perhaps I should re-release 1.5.2 as 1.6.2 until the windows
>             support
>             in 1.6
>             gets sorted out.
>
>
>         Give me 24 hours to try and fix this please. I don't want to go
>         back to
>         1.5.2 if we can help it.
>
>
>     How come you didn't properly test this before you released?
>     Seems like there have been a number of issues that have come up with
>     the 1.6 release that should have *really* been caught before it was
>     foisted upon people...
>
>
> Can you please ask all of these questions on a list somewhere? I don't
> want to get into it one-on-one, it's too long of a story.

So, what's the long story? Buildout grows two new contributors and 
suddenly we don't care about quality and/or Windows support anymore?

Chris

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

From agroszer.ll at gmail.com  Wed Aug 22 10:07:14 2012
From: agroszer.ll at gmail.com (Adam GROSZER)
Date: Wed, 22 Aug 2012 10:07:14 +0200
Subject: [Distutils] buildout 1.6 on windows
In-Reply-To: <50347C74.40203@simplistix.co.uk>
References: <5033EFFD.1070608@simplistix.co.uk>
	<CAPDm-FjgUGoevnvbPR64ddqOc1_T4Ji_a9LHAi0W+=rWWZXG1w@mail.gmail.com>
	<k112nl$98v$1@ger.gmane.org> <50340FDA.40408@simplistix.co.uk>
	<CAKAV2_nv2h3+gumvnDB4srMfnF0VB7XMRa0bU=mOyQrrMJ8N5w@mail.gmail.com>
	<50347C74.40203@simplistix.co.uk>
Message-ID: <50349332.2050905@gmail.com>

On 08/22/2012 08:30 AM, Chris Withers wrote:
> Hi All,
>
> At Alex's request:
>
> On 21/08/2012 23:56, Alex Clark wrote:
>> On Tue, Aug 21, 2012 at 6:46 PM, Chris Withers <chris at simplistix.co.uk
>> <mailto:chris at simplistix.co.uk>> wrote:
>>
>>     Alex,
>>
>>     On 21/08/2012 23:39, Alex Clark wrote:
>>
>>             Perhaps I should re-release 1.5.2 as 1.6.2 until the windows
>>             support
>>             in 1.6
>>             gets sorted out.
>>
>>
>>         Give me 24 hours to try and fix this please. I don't want to go
>>         back to
>>         1.5.2 if we can help it.
>>
>>
>>     How come you didn't properly test this before you released?
>>     Seems like there have been a number of issues that have come up with
>>     the 1.6 release that should have *really* been caught before it was
>>     foisted upon people...
>>
>>
>> Can you please ask all of these questions on a list somewhere? I don't
>> want to get into it one-on-one, it's too long of a story.
>
> So, what's the long story? Buildout grows two new contributors and
> suddenly we don't care about quality and/or Windows support anymore?
>
> Chris
>

So to move this on, winbot now builds zc.buildout
- master with python 2.6, 2.7 32 and 64 bit
- "1.6.x" with python 2.5 32 bit, 2.6, 2.7 32 and 64 bit

http://winbot.zope.org/builders


-- 
Best regards,
  Adam GROSZER
--
Quote of the day:
Leaves have their time to fall, And flowers to wither at the 
north-wind's breath, And stars to set; but all, Thou hast all seasons 
for thine own, O Death!
- Felicia D. Hemas

From regebro at gmail.com  Wed Aug 22 12:10:52 2012
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 22 Aug 2012 12:10:52 +0200
Subject: [Distutils] Distribute tests.
Message-ID: <CAL0kPAW6Gtv897RwbQ+15u+BZpdCpy3Jd7eP5m2QT+TU+kmrNw@mail.gmail.com>

Most of the tests for distribute are run with "python setup.py test",
but there is a whole bunch of tests in ./tests and they are not run.
Anyone know how the *should* be run? Just running them creates various
errors, clearly there is some sort of setup needed first.

//Lennart

From agroszer at gmail.com  Fri Aug 24 11:08:00 2012
From: agroszer at gmail.com (Adam GROSZER)
Date: Fri, 24 Aug 2012 11:08:00 +0200
Subject: [Distutils] distribute buildbot
Message-ID: <50374470.40105@gmail.com>

Hello,

Are there any buildbots for distribute?

-- 
Best regards,
  Adam GROSZER
--
Quote of the day:
Men do not reject the Bible because it contradicts itself but because it 
contradicts them.
- The Defender

From vs at it.uu.se  Tue Aug 28 11:32:20 2012
From: vs at it.uu.se (Virgil Stokes)
Date: Tue, 28 Aug 2012 11:32:20 +0200
Subject: [Distutils] Question on distutils.cfg and problem with installation
	of yappi
Message-ID: <503C9024.5070306@it.uu.se>

I have only recently joined this list --- hopefully my first mail to this list 
is acceptable.

*First*, is it possible to place comments in the distutils.cfg file?

*Second*, I have been unable to install yappi (included in the PyPI list) on my 
Windows 7 (64-bit) platform with Python 2.7 (32-bit) and would greatly 
appreciate help on this installation.

Note, I have installed many other PyPI packages on this same system with no 
problems where I have cygwin, minGW (32-bit) and minGW (64-bit) gcc and g++ 
compilers installed and working properly. I have installed yappi on my Windows 
Vista (32-bit) platform with Python 2.7. I have also studied the information 
posted by Greg Ward at http://docs.python.org/install/index.html.

Here are some of the results of my attempts to install yappi on the Windows 7 
system.

I looked at what compilers are available for building from my setup.py
file:

c:\Software\Python\yappi\yappi-0.62>python setup.py build --help-compiler
      List of available compilers:
        --compiler=bcpp     Borland C++ Compiler
        --compiler=cygwin   Cygwin port of GNU C Compiler for Win32
        --compiler=emx      EMX port of GNU C Compiler for OS/2
        --compiler=mingw32  Mingw32 port of GNU C Compiler for Win32
        --compiler=msvc     Microsoft Visual C++
        --compiler=unix     standard UNIX-style compiler

I then tried the following:

c:\Software\Python\yappi\yappi-0.62>python setup.py build --compiler=cygwin
       running build
       running build_py
       running build_ext
       building '_yappi' extension
       gcc -mcygwin -mdll -O -Wall -IC:\Python27\include -IC:\Python27\PC -c  
_yappi.c -o build\temp.win32-2.7\Release\_yappi.o
       error: command 'gcc' failed: No such file or directory

I then tried to be more specific,

c:\Software\Python\yappi\yappi-0.62>python setup.py build
       --compiler=c:\cygwin\bin\gcc.exe
       running build
       running build_py
       running build_ext
       building '_yappi' extension
       error: don't don't know how to compile C/C++ code on platform 'nt' with 
'c:\cygwin\bin\gcc.exe' compiler

I also tried many other possible (at least IMHO) solutions --- these also
failed. For example,

c:\Software\Python\yappi\yappi-0.62>python setup.py build --compiler=msvc
       running build
       running build_py
       running build_ext
       building '_yappi' extension
       error: Unable to find vcvarsall.bat

I then modified the c:\python27\Lib\distutils\distutils.cfg file and set
different compilers in it --- these also failed.

The bottom line --- all my trials (attempts) failed for one reason or another.

Any suggestions as to how to proceed? I will be glad to provide any additional
information on my trials.

--V

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

From agroszer.ll at gmail.com  Wed Aug 29 12:43:12 2012
From: agroszer.ll at gmail.com (Adam GROSZER)
Date: Wed, 29 Aug 2012 12:43:12 +0200
Subject: [Distutils] distribute buildbot
In-Reply-To: <50374470.40105@gmail.com>
References: <50374470.40105@gmail.com>
Message-ID: <503DF240.2010201@gmail.com>

To answer myself, winbot.zooe.org builds now distribute

On 08/24/2012 11:08 AM, Adam GROSZER wrote:
> Hello,
>
> Are there any buildbots for distribute?
>


-- 
Best regards,
  Adam GROSZER
--
Quote of the day:
Rudin's Law: In a crisis that forces a choice to be made among 
alternative courses of action, most people will choose the worst one 
possible.