From setuptools at bugs.python.org  Thu Aug  4 12:56:19 2011
From: setuptools at bugs.python.org (Florian)
Date: Thu, 04 Aug 2011 10:56:19 +0000
Subject: [Distutils] [issue131] Shebang for gui_scripts on Windows is not
	changed to	pythonw
In-Reply-To: <1312455379.53.0.0183070756797.issue131@psf.upfronthosting.co.za>
Message-ID: <1312455379.53.0.0183070756797.issue131@psf.upfronthosting.co.za>


New submission from Florian <florian.dorn at gmail.com>:

When creating a wininst, get_script_header alwasy sets the executabe to "python.exe".

Thus, in get_script_args() the code to check if the header should actually be changed should be updated to:
if os.path.exists(new_header[2:-1]) or wininst or sys.platform!='win32':
    hdr = new_header
else:
    hdr = header

----------
messages: 630
nosy: flocki
priority: bug
status: unread
title: Shebang for gui_scripts on Windows is not changed to pythonw

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

From distutils-sig at webhippo.net  Fri Aug  5 05:02:41 2011
From: distutils-sig at webhippo.net (Michael)
Date: Thu, 04 Aug 2011 20:02:41 -0700
Subject: [Distutils] "Safe" Project Names and underscores in Project Names
	issue
Message-ID: <11358b0d97e22ed75db935343b930f77@mail.mxes.net>

 Forgive me if I ask a stupid question but what characters are allowed 
 in a project name on PyPI and by Distribute/Setuptools?
 I specifically ask because of what I think is a problem I found with 
 Distribute/Setuptools with the underscore character ("_")

 It seems PyPI allows underscore as a valid character in a project name 
 and as such there are projects like pyramid_beaker, django_email_auth. 
 Distributes' behaviour is to replace all underscores to dashes using the 
 safe_name function 
 (https://bitbucket.org/tarek/distribute/src/611910892a04/pkg_resources.py#cl-1135). 
 Project name is registered with dashes in the egg (i.e pyramid-beaker) 
 and nowhere is the original name stored.

 It seems, following lead Pip has adjusted its code accordingly 
 (https://github.com/pypa/pip/blob/ea60bb79b5f837f0aa36d2354415dbcca5368afe/pip/index.py#L317) 
 As such, modifying the safe_name method to recognize undescore breaks 
 pip.

 Doing "pip install pyramid_beaker" installs the package successfully 
 however any package tools (i.e pip) report the project as 
 "pyramid-beaker" and as such becomes unusable name if PyPI is queried 
 via RPC Interfaces. Trying to turn all the dashes back underscores 
 breaks packages that have underscores in them (i.e. 
 sphinxcontrib-programoutput). And if the package were to use both, it 
 would be impossible to determine what it is without running all the 
 permutations.

 I would appreciate if any one could advise me on this matter and let me 
 know if this is a bug underscore treatment with Distribute/Setuptools, 
 pip or PyPI.


 Here is the test code to reproduce the problem (in a virtualenv):

 1. Setup a test virtualenv with "--distribute --no-site-packages" and 
 activate it

 2. Install following packages:

 pip install --ignore-installed --no-deps pyramid_beaker
 pip install --ignore-installed --no-deps sphinxcontrib-programoutput

 3. Save and run the following script that uses pip and XMLRPC to check 
 for new versions:
 --------------------------------
 import xmlrpclib
 import pip

 pypi = xmlrpclib.ServerProxy('http://pypi.python.org/pypi')
 for dist in pip.get_installed_distributions():
     available = pypi.package_releases(dist.project_name)
     if not available:
         # Try to capitalize pkg name
         available = 
 pypi.package_releases(dist.project_name.capitalize())

     if not available:
         msg = 'no releases at pypi'
     elif available[0] != dist.version:
         msg = '{} available'.format(available[0])
     else:
         msg = 'up to date'
     pkg_info = '{dist.project_name} {dist.version}'.format(dist=dist)
     print '{pkg_info:40} {msg}'.format(pkg_info=pkg_info, msg=msg)

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

 Output (specific to installed packages):

 sphinxcontrib-programoutput 0.4.1        up to date
 pyramid-beaker 0.5                       no releases at pypi

 [pyramid-beaker does not exist on PyPI, since its pyramid_beaker)


 Expected output (mind the underscores)

 sphinxcontrib-programoutput 0.4.1        up to date
 pyramid_beaker 0.5                       up to date

 ---- Additional info ---
 pyramid_beaker-0.5-py2.7.egg-info/PKG-INFO shows that the project name 
 is:

 Name: pyramid-beaker



From pje at telecommunity.com  Fri Aug  5 06:05:23 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Fri, 05 Aug 2011 00:05:23 -0400
Subject: [Distutils] "Safe" Project Names and underscores in Project
 Names issue
In-Reply-To: <11358b0d97e22ed75db935343b930f77@mail.mxes.net>
References: <11358b0d97e22ed75db935343b930f77@mail.mxes.net>
Message-ID: <20110805040641.8A1CF3A4116@sparrow.telecommunity.com>

At 08:02 PM 8/4/2011 -0700, Michael wrote:
>Forgive me if I ask a stupid question but what characters are 
>allowed in a project name on PyPI and by Distribute/Setuptools?

Setuptools allows names that have been processed through safe_name.


>As such, modifying the safe_name method to recognize undescore breaks pip.

Why are you modifying the safe_name function?  If you change it, 
it'll no longer be safe.  ;-)



>Doing "pip install pyramid_beaker" installs the package successfully 
>however any package tools (i.e pip) report the project as 
>"pyramid-beaker" and as such becomes unusable name if PyPI is 
>queried via RPC Interfaces. Trying to turn all the dashes back 
>underscores breaks packages that have underscores in them (i.e. 
>sphinxcontrib-programoutput). And if the package were to use both, 
>it would be impossible to determine what it is without running all 
>the permutations.
>
>I would appreciate if any one could advise me on this matter and let 
>me know if this is a bug underscore treatment with 
>Distribute/Setuptools, pip or PyPI.

It's a PyPI incompatibility - neither the distutils nor PyPI were 
originally designed for a world involving automatically-resolved 
dependencies, where names needed to be unambiguous.  That is, PyPI 
and distutils had an implicit assumption that 1) people would choose 
reasonable names and 2) be able to handle it when other people didn't.

Setuptools, on the other hand, needs unambiguous naming, and 
therefore has a canonicalization algorithm that's designed to work 
reasonably well with distutils' file naming conventions.  Distutils 
normally uses '-' to separate name parts in a filename, and 
(sometimes) escapes '-' using '_'.  So setuptools canonicalizes all 
punctuation to '-', and escapes it as '_'.

Some of PyPI's code has been changed to work with this approach, and 
some has not.


>[pyramid-beaker does not exist on PyPI, since its pyramid_beaker)

 From setuptools POV, the package name is pyramid-beaker, because '_' 
is reserved for escaping punctuation in filenames.

If you want to look up a setuptools package name using PyPI XML-RPC, 
you can't always use the name directly; you may have to perform a 
PyPI search operation to obtain the package's PyPI name first.


From chris at simplistix.co.uk  Sat Aug 13 11:15:17 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 13 Aug 2011 10:15:17 +0100
Subject: [Distutils] buildout-versions now on github
Message-ID: <4E4640A5.6020909@simplistix.co.uk>

Hi All,

In an effort to make it easier to get involved, I've moved 
buildout-versions to github:

https://github.com/Simplistix/buildout-versions

cheers,

Chris

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

From reinout at vanrees.org  Tue Aug 16 13:45:48 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 16 Aug 2011 13:45:48 +0200
Subject: [Distutils] Which buildout to use?
Message-ID: <j2dl9d$m4t$1@dough.gmane.org>

Hi,

There's buildout 1.4.4, 1.5.2 and an alpha of 2.0.

The 2.0 seems to aim at python 3 and is, according to the docs, in a 
very early alpha stage, so I'll leave that one out.

What I'm using now is 1.4.4 with the special bootstrap.py that ensures 
it picks 1.4.4 instead of a newer one. The reason: it works with 
http://pypi.python.org/pypi/osc.recipe.sysegg which finds system wide 
python packages (numpy and other stuff better installed through the OS).

I tried 1.5.x half a year ago, but it didn't find numpy&friends on 
ubuntu even though 1.5 is supposed to allow just that. I tried it this 
morning on OSX with 1.5.2 but still no luck. It doesn't want to find the 
OS-level packages.

But... sticking to ye olde 1.4.4 seems wrong to me. So I phoned my 
brother Maurits (hi!) who is working with plone: plone is a heavy 
buildout user, so what's the status there? He said plone is basically 
also still on 1.4.4!


a) I feel a bit better sticking to 1.4.4, knowing that plone also does it.

b) Is anyone actually using 1.5.2 with system packages? And by that I 
mean that you have a dependency on something like numpy and buildout 
actually finds that package locally and won't try and grab it off pypi?

Am I doing something wrong? I dare say I've got an above average 
experience with buidout and I just can't get this to work.



Reinout


p.s.: Here's my buildout config. Am I doing something completely wrong?

   [buildout]
   parts = scripts
   include-site-packages = true
   allowed-eggs-from-site-packages =
       numpy

   [scripts]
   recipe = zc.recipe.egg
   eggs =
       numpy


-- 
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 fdrake at acm.org  Tue Aug 16 14:10:37 2011
From: fdrake at acm.org (Fred Drake)
Date: Tue, 16 Aug 2011 08:10:37 -0400
Subject: [Distutils] Which buildout to use?
In-Reply-To: <j2dl9d$m4t$1@dough.gmane.org>
References: <j2dl9d$m4t$1@dough.gmane.org>
Message-ID: <CAFT4OTEcFfgPg55QQG0CAn3QwmDkyMx3xHFNE1ooWYM4N-OdkA@mail.gmail.com>

On Tue, Aug 16, 2011 at 7:45 AM, Reinout van Rees <reinout at vanrees.org> wrote:
> But... sticking to ye olde 1.4.4 seems wrong to me. So I phoned my brother
> Maurits (hi!) who is working with plone: plone is a heavy buildout user, so
> what's the status there? He said plone is basically also still on 1.4.4!

We're mostly using zc.buildout 1.4.4 at Zope Corporation (home of zc.buildout)
as well.  Except where we're using older version (which will get updated
before too much longer).

Buildout 1.5.x introduced features we just haven't needed.


  -Fred

-- 
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A person who won't read has no advantage over one who can't read."
?? --Samuel Langhorne Clemens

From reinout at vanrees.org  Tue Aug 16 14:34:00 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 16 Aug 2011 14:34:00 +0200
Subject: [Distutils] buildout-versions now on github
In-Reply-To: <4E4640A5.6020909@simplistix.co.uk>
References: <4E4640A5.6020909@simplistix.co.uk>
Message-ID: <j2do3o$802$1@dough.gmane.org>

On 13-08-11 11:15, Chris Withers wrote:
> Hi All,
>
> In an effort to make it easier to get involved, I've moved
> buildout-versions to github:
>
> https://github.com/Simplistix/buildout-versions

buildout-versions 1.6 requires buildout >= 1.5

Your recipe was one of the things that prompted me to re-investigate 
whether I could get buildout 1.5 to work :-)

Not getting buildout 1.5 to work means I have to pin more and more 
things to older versions, which isn't something I want to keep doing 
obviously. It is also something that's virtually impossible to explain 
to potential new buildout users.



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 me at aatiis.me  Tue Aug 16 14:41:20 2011
From: me at aatiis.me (=?UTF-8?B?QXR0aWxhIE9sw6Fo?=)
Date: Tue, 16 Aug 2011 14:41:20 +0200
Subject: [Distutils] Which buildout to use?
In-Reply-To: <j2dl9d$m4t$1@dough.gmane.org>
References: <j2dl9d$m4t$1@dough.gmane.org>
Message-ID: <CAFKz0Aya8Bb_-vxBZooZj8dyTnQvKwaZ4wUenx-oEUVSX424sA@mail.gmail.com>

Hello,

On Tue, Aug 16, 2011 at 13:45, Reinout van Rees <reinout at vanrees.org> wrote:
> b) Is anyone actually using 1.5.2 with system packages? And by that I mean
> that you have a dependency on something like numpy and buildout actually
> finds that package locally and won't try and grab it off pypi?

Yes, we use zc.buildout-1.5.2 with a project that runs Pyramid on
Google's App Engine. I run the development environment in Gentoo, and
I have net-zope/zope-interface installed in
/usr/lib64/python?.?/site-packages/zope/interface. When I run buildout
with a system Python that's ABI is supported by the zope-inteface
ebuild, it will use the one from the system site-packages. IOW,
worksforme.

Have you tried the allowed-eggs-from-site-packages [1] option?

[1] http://pypi.python.org/pypi/zc.buildout/1.5.2#working-with-a-system-python

Attila

From reinout at vanrees.org  Tue Aug 16 15:40:24 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 16 Aug 2011 15:40:24 +0200
Subject: [Distutils] Which buildout to use?
In-Reply-To: <CAFKz0Aya8Bb_-vxBZooZj8dyTnQvKwaZ4wUenx-oEUVSX424sA@mail.gmail.com>
References: <j2dl9d$m4t$1@dough.gmane.org>
	<CAFKz0Aya8Bb_-vxBZooZj8dyTnQvKwaZ4wUenx-oEUVSX424sA@mail.gmail.com>
Message-ID: <j2ds08$2p5$1@dough.gmane.org>

On 16-08-11 14:41, Attila Ol?h wrote:
> Hello,
>
> On Tue, Aug 16, 2011 at 13:45, Reinout van Rees<reinout at vanrees.org>  wrote:
>> b) Is anyone actually using 1.5.2 with system packages? And by that I mean
>> that you have a dependency on something like numpy and buildout actually
>> finds that package locally and won't try and grab it off pypi?
>
> Yes, we use zc.buildout-1.5.2 with a project that runs Pyramid on
> Google's App Engine. I run the development environment in Gentoo, and
> I have net-zope/zope-interface installed in
> /usr/lib64/python?.?/site-packages/zope/interface. When I run buildout
> with a system Python that's ABI is supported by the zope-inteface
> ebuild, it will use the one from the system site-packages. IOW,
> worksforme.

Just making sure: you have a dependency on zope.interface in your 
setup.py's install_requires? So that buildout actively searches for it?


(ABI compatibility... I *did* upgrade to OSX Lion and installing some 
things give me an "cannot find gcc-4.0" error. But when running my 
sites, mapnik and the other libraries work just fine, so I think that 
shouldn't be the problem. But I don't know what buildout 1.5 does in 
detail.)

> Have you tried the allowed-eggs-from-site-packages [1] option?

Yes. Didn't have any effect, it seemed.



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 chris at simplistix.co.uk  Tue Aug 16 16:33:46 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 16 Aug 2011 07:33:46 -0700
Subject: [Distutils] Which buildout to use?
In-Reply-To: <j2dl9d$m4t$1@dough.gmane.org>
References: <j2dl9d$m4t$1@dough.gmane.org>
Message-ID: <4E4A7FCA.2000406@simplistix.co.uk>

On 16/08/2011 04:45, Reinout van Rees wrote:
> Hi,
>
> There's buildout 1.4.4, 1.5.2 and an alpha of 2.0.

I've used 1.5.2 happily for ages, but I don't use the stuff Gary 
introduced there...

cheers,

Chris

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

From chris at simplistix.co.uk  Tue Aug 16 16:38:50 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 16 Aug 2011 07:38:50 -0700
Subject: [Distutils] buildout-versions now on github
In-Reply-To: <j2do3o$802$1@dough.gmane.org>
References: <4E4640A5.6020909@simplistix.co.uk> <j2do3o$802$1@dough.gmane.org>
Message-ID: <4E4A80FA.7040005@simplistix.co.uk>

On 16/08/2011 05:34, Reinout van Rees wrote:
> On 13-08-11 11:15, Chris Withers wrote:
>> Hi All,
>>
>> In an effort to make it easier to get involved, I've moved
>> buildout-versions to github:
>>
>> https://github.com/Simplistix/buildout-versions
>
> buildout-versions 1.6 requires buildout >= 1.5
>
> Your recipe was one of the things that prompted me to re-investigate
> whether I could get buildout 1.5 to work :-)

I have a suspicion, the problems solved with 1.6 only appear when used 
with Buildout 1.5+, but I can't remember for sure...

> Not getting buildout 1.5 to work means I have to pin more and more
> things to older versions, which isn't something I want to keep doing
> obviously. It is also something that's virtually impossible to explain
> to potential new buildout users.

What needs explaining?

If you have problems with 1.5, Gary Poster is your man :-)

cheers,

Chris

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

From chris at simplistix.co.uk  Tue Aug 16 16:50:58 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 16 Aug 2011 07:50:58 -0700
Subject: [Distutils] "buildout-versions" not showing pinned versions
In-Reply-To: <CAHheN2n0f=wkXPeyL=xOOPrpeMkKfs5vn6+8w34qcb=u54ym_g@mail.gmail.com>
References: <CAHheN2nh1Ndfa=RZZgP74tRRE2e=ANGS+15HFEUnWhW+y7u-fg@mail.gmail.com>
	<4E464069.9060401@simplistix.co.uk>
	<CAHheN2n0f=wkXPeyL=xOOPrpeMkKfs5vn6+8w34qcb=u54ym_g@mail.gmail.com>
Message-ID: <4E4A83D2.4050501@simplistix.co.uk>

Hi,

I've CC'ed in the correct mailing list for these discussions, you should 
mail there first in future.

Right, replaying our discussion in it's original order:

 >     On 13/08/2011 04:04, B.Nanda Kishore wrote:
 >
 >         when my buildout.cfg is having content like:
 >         *[buildout]*
 >         *parts = deps*
 >         *extensions = buildout-versions*
 >         *
 >         *
 >         *[deps]*
 >         *recipe = zc.recipe.egg*
 >         *eggs = Django*
 >
 >         and when I run buildout its printing the latest Django 
version(1.3).
 >         Thats fine. But.....
 >         when I pin the version number of Django in buildout.cfg to 
something

Okay, so it looks like you're pinning versions as follows:

On 15/08/2011 06:20, B.Nanda Kishore wrote:
 > Here is my buildout.cfg:
 > [buildout]
 > parts = deps
 > extensions = buildout-versions
 >
 > [deps]
 > recipe = zc.recipe.egg
 > eggs = *Django==1.0.4*

As an aside, I'll point out that the above buildout.cfg doesn't do 
anything useful as Django doesn't expose any setuptools-style console 
scripts.

Now, buildout-versions won't report any versions here since you've 
pinned Django to 1.0.4. It only warns about un-pinned versions of eggs.

Here's a minimal useful recipe that pins Django in a more orthodox 
fashion and provides a bin/py interpreter that will that version 1.0.4 
of django available:

[buildout]
parts = deps
extensions = buildout-versions
versions = versions

[versions]
buildout-versions = 1.6
Django = 1.0.4
setuptools = 0.6c12dev-r88846
zc.buildout = 1.5.2
zc.recipe.egg = 1.3.2

[deps]
recipe = zc.recipe.egg
eggs = Django
interpreter = py

However, I'd suggest looking at the djangorecipe package as a much more 
useful way of dealing with Django in buildout!

cheers,

Chris

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

From jim at zope.com  Tue Aug 16 17:01:24 2011
From: jim at zope.com (Jim Fulton)
Date: Tue, 16 Aug 2011 11:01:24 -0400
Subject: [Distutils] Which buildout to use?
In-Reply-To: <CAFT4OTEcFfgPg55QQG0CAn3QwmDkyMx3xHFNE1ooWYM4N-OdkA@mail.gmail.com>
References: <j2dl9d$m4t$1@dough.gmane.org>
	<CAFT4OTEcFfgPg55QQG0CAn3QwmDkyMx3xHFNE1ooWYM4N-OdkA@mail.gmail.com>
Message-ID: <CAPDm-Fhc_5yJKWq9NC6HnwosNgVY=c1NNOC5VJ+vHGF0GjEY3w@mail.gmail.com>

On Tue, Aug 16, 2011 at 8:10 AM, Fred Drake <fdrake at acm.org> wrote:
> On Tue, Aug 16, 2011 at 7:45 AM, Reinout van Rees <reinout at vanrees.org> wrote:
>> But... sticking to ye olde 1.4.4 seems wrong to me. So I phoned my brother
>> Maurits (hi!) who is working with plone: plone is a heavy buildout user, so
>> what's the status there? He said plone is basically also still on 1.4.4!
>
> We're mostly using zc.buildout 1.4.4 at Zope Corporation (home of zc.buildout)
> as well. ?Except where we're using older version (which will get updated
> before too much longer).
>
> Buildout 1.5.x introduced features we just haven't needed.

I use 1.5. :)

I don't personally care about integration with system Python or
system packages.

I do plan to keep maintaining 1.5. I don't plan maintenance on 1.4.
Of course, I plan to support 2x over the long term.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton

From me at aatiis.me  Tue Aug 16 17:04:04 2011
From: me at aatiis.me (=?UTF-8?B?QXR0aWxhIE9sw6Fo?=)
Date: Tue, 16 Aug 2011 17:04:04 +0200
Subject: [Distutils] Which buildout to use?
In-Reply-To: <j2ds08$2p5$1@dough.gmane.org>
References: <j2dl9d$m4t$1@dough.gmane.org>
	<CAFKz0Aya8Bb_-vxBZooZj8dyTnQvKwaZ4wUenx-oEUVSX424sA@mail.gmail.com>
	<j2ds08$2p5$1@dough.gmane.org>
Message-ID: <CAFKz0Azfp8e-ryT45dfadr7b=u-bSK4z7HUVL-OTpWMOjV_xpQ@mail.gmail.com>

On Tue, Aug 16, 2011 at 15:40, Reinout van Rees <reinout at vanrees.org> wrote:
> On 16-08-11 14:41, Attila Ol?h wrote:
>>
>> Hello,
>>
>> On Tue, Aug 16, 2011 at 13:45, Reinout van Rees<reinout at vanrees.org>
>> ?wrote:
>>>
>>> b) Is anyone actually using 1.5.2 with system packages? And by that I
>>> mean
>>> that you have a dependency on something like numpy and buildout actually
>>> finds that package locally and won't try and grab it off pypi?
>>
>> Yes, we use zc.buildout-1.5.2 with a project that runs Pyramid on
>> Google's App Engine. I run the development environment in Gentoo, and
>> I have net-zope/zope-interface installed in
>> /usr/lib64/python?.?/site-packages/zope/interface. When I run buildout
>> with a system Python that's ABI is supported by the zope-inteface
>> ebuild, it will use the one from the system site-packages. IOW,
>> worksforme.
>
> Just making sure: you have a dependency on zope.interface in your setup.py's
> install_requires? So that buildout actively searches for it?

Good point. It wasn't there, I only listed "pyramid" and a bunch of
other packages. Let's add it and experiment.

Let's update zope-interface first:

$ sudo emerge --update --oneshot zope-interface
[...]
 *
 * Python namespaces:
 *     '/usr/lib64/python2.6/site-packages/zope.interface-3.7.0-py2.6-nspkg.pth':
 *         zope
 *     '/usr/lib64/python3.1/site-packages/zope.interface-3.7.0-py3.1-nspkg.pth':
 *         zope
 *     '/usr/lib64/python2.4/site-packages/zope.interface-3.7.0-py2.4-nspkg.pth':
 *         zope
 *     '/usr/lib64/python2.7/site-packages/zope.interface-3.7.0-py2.7-nspkg.pth':
 *         zope
 *     '/usr/lib64/python3.2/site-packages/zope.interface-3.7.0-py3.2-nspkg.pth':
 *         zope
 *     '/usr/lib64/python2.5/site-packages/zope.interface-3.7.0-py2.5-nspkg.pth':
 *         zope
 *
[...]

Now I update setup.py, adding a few packages just for testing:

$ git clone vemble tmp && cd tmp
$ vim setip.py
$ grep req setup.py
    install_requires=('zope.interface', 'numpy', 'scipy', 'nose', 'six'),

Note that I'll use a simplified buildout.cfg for testing:

$ cat buildout.cfg
[buildout]
develop = .
parts =
    graph
unzip = true

[graph]
recipe = z3c.recipe.depgraph
eggs = vemble
variants = tred
strict = true


Check Python version:

$ python -V
Python 2.7.2+

Note that I have zope.interface, numpy, scipy and nose on my systme. I
do not have 'six' though.

$ python -c "print __import__('zope.interface').interface"
<module 'zope.interface' from
'/usr/lib64/python2.7/site-packages/zope/interface/__init__.pyc'>
$ python -c "print __import__('numpy')"
<module 'numpy' from '/usr/lib64/python2.7/site-packages/numpy/__init__.pyc'>
$ python -c "print __import__('scipy')"
<module 'scipy' from '/usr/lib64/python2.7/site-packages/scipy/__init__.pyc'>
$ python -c "print __import__('nose')"
<module 'nose' from '/usr/lib64/python2.7/site-packages/nose/__init__.pyc'>

$ python bootstrap.py --distribute
[...]
$ ls eggs
zc.buildout-1.5.2-py2.7.egg
$ ./bin/buildout
[...]
Egg from site-packages: distribute 0.6.19
[...]
Getting distribution for 'six'.
Running easy_install:
[...]
Got six 1.0.0.
Picked: six = 1.0.0
[...]
Getting required 'nose'
  required by vemble 0.
We have the best distribution that satisfies 'nose'.
Egg from site-packages: nose 1.1.2
Getting required 'scipy'
  required by vemble 0.
We have the best distribution that satisfies 'scipy'.
Egg from site-packages: scipy 0.9.0
Getting required 'numpy'
  required by vemble 0.
We have the best distribution that satisfies 'numpy'.
Egg from site-packages: numpy 1.6.1
Getting required 'zope.interface'
  required by vemble 0.
We have the best distribution that satisfies 'zope.interface'.
Egg from site-packages: zope.interface 3.7.0

$ ls -1 eggs
six-1.0.0-py2.7.egg
tl.eggdeps-0.4-py2.7.egg
z3c.recipe.depgraph-0.5-py2.7.egg
zc.buildout-1.5.2-py2.7.egg
zc.recipe.egg-1.3.2-py2.7.egg

$ cat bin/graph-graph
[...]

import sys
sys.path[0:0] = [
    '/home/aatiis/repos/tmp/src',
    '/home/aatiis/repos/tmp/eggs/z3c.recipe.depgraph-0.5-py2.7.egg',
    '/home/aatiis/repos/tmp/eggs/tl.eggdeps-0.4-py2.7.egg',
    '/home/aatiis/repos/tmp/eggs/zc.recipe.egg-1.3.2-py2.7.egg',
    '/home/aatiis/repos/tmp/eggs/zc.buildout-1.5.2-py2.7.egg',
    '/usr/lib64/python2.7/site-packages',
    '/usr/lib64/python2.7/site-packages',
    '/usr/lib64/python2.7/site-packages',
    '/usr/lib64/python2.7/site-packages',
    '/usr/lib64/python2.7/site-packages',
    '/home/aatiis/repos/tmp/eggs/six-1.0.0-py2.7.egg',
    ]

[...]

As you can see, it uses '/usr/lib64/python2.7/site-packages' multiple
times, for all the packages that I have on my system.

Note that I used to have some problems with this on Ubuntu, but with
Gentoo it works just fine.

> (ABI compatibility... I *did* upgrade to OSX Lion and installing some things
> give me an "cannot find gcc-4.0" error. But when running my sites, mapnik
> and the other libraries work just fine, so I think that shouldn't be the
> problem. But I don't know what buildout 1.5 does in detail.)

I have the following ABIs enabled:

$ eix zope-interface | grep -i installed
     Installed versions:  3.7.0{tbz2}[1](16:37:53
16/08/11)(python_abis_2.4 python_abis_2.5 python_abis_2.6
python_abis_2.7 python_abis_3.1 python_abis_3.2
-python_abis_2.5-jython -python_abis_2.7-pypy-1.5 -python_abis_3.3)

This basically means that zope.interface is installed in the
site-packages of my Python 2.4 (though it fails with this version),
2.5, 2.6, 2.7, 3.1 and 3.2, and not installed for Python 3.3, Jython
and PyPy.

Also note that Gentoo correctly installs these Python packages as
eggs, including their .egg-info directory.

I hope I could be of some help!

Cheers,

Attila

>> Have you tried the allowed-eggs-from-site-packages [1] option?
>
> Yes. Didn't have any effect, it seemed.
>
>
>
> 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"
>
> _______________________________________________
> Distutils-SIG maillist ?- ?Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>

From reinout at vanrees.org  Tue Aug 16 17:29:37 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 16 Aug 2011 17:29:37 +0200
Subject: [Distutils] Which buildout to use?
In-Reply-To: <CAFKz0Azfp8e-ryT45dfadr7b=u-bSK4z7HUVL-OTpWMOjV_xpQ@mail.gmail.com>
References: <j2dl9d$m4t$1@dough.gmane.org>
	<CAFKz0Aya8Bb_-vxBZooZj8dyTnQvKwaZ4wUenx-oEUVSX424sA@mail.gmail.com>
	<j2ds08$2p5$1@dough.gmane.org>
	<CAFKz0Azfp8e-ryT45dfadr7b=u-bSK4z7HUVL-OTpWMOjV_xpQ@mail.gmail.com>
Message-ID: <j2e2d1$fjk$1@dough.gmane.org>

On 16-08-11 17:04, Attila Ol?h wrote:
> Getting required 'nose'
>    required by vemble 0.
> We have the best distribution that satisfies 'nose'.
> Egg from site-packages: nose 1.1.2
> Getting required 'scipy'
>    required by vemble 0.
> We have the best distribution that satisfies 'scipy'.
> Egg from site-packages: scipy 0.9.0
> Getting required 'numpy'
>    required by vemble 0.
> We have the best distribution that satisfies 'numpy'.
> Egg from site-packages: numpy 1.6.1
> Getting required 'zope.interface'
>    required by vemble 0.
> We have the best distribution that satisfies 'zope.interface'.
> Egg from site-packages: zope.interface 3.7.0

That's pretty convincing, thanks for trying it out!

So on gentoo it works. On Ubuntu it doesn't (at least half a year ago, 
but that was already with 1.5.2 iirc) and on OSX it doesn't (as far as I 
can see).

Anyone on OSX or ubuntu who got it to work? I'd dearly like to get it to 
work, too.



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 sdouche at gmail.com  Tue Aug 16 17:46:12 2011
From: sdouche at gmail.com (Sebastien Douche)
Date: Tue, 16 Aug 2011 17:46:12 +0200
Subject: [Distutils] Which buildout to use?
In-Reply-To: <j2dl9d$m4t$1@dough.gmane.org>
References: <j2dl9d$m4t$1@dough.gmane.org>
Message-ID: <CAAGHeXGFWojBDgcKXLzuwe1wgmNncRd80sgnoicbOzbQX_VVww@mail.gmail.com>

On Tue, Aug 16, 2011 at 13:45, Reinout van Rees <reinout at vanrees.org> wrote:
> ?recipe = zc.recipe.egg

zc.recipe.egg can handle the new buildout options? When I want system
packages I use z3.recipe.scripts :
http://pypi.python.org/pypi/z3c.recipe.scripts/

-- 
Sebastien Douche <sdouche at gmail.com>
Twitter : @sdouche

From reinout at vanrees.org  Tue Aug 16 17:56:25 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 16 Aug 2011 17:56:25 +0200
Subject: [Distutils] Which buildout to use?
In-Reply-To: <CAAGHeXGFWojBDgcKXLzuwe1wgmNncRd80sgnoicbOzbQX_VVww@mail.gmail.com>
References: <j2dl9d$m4t$1@dough.gmane.org>
	<CAAGHeXGFWojBDgcKXLzuwe1wgmNncRd80sgnoicbOzbQX_VVww@mail.gmail.com>
Message-ID: <j2e3va$q95$1@dough.gmane.org>

On 16-08-11 17:46, Sebastien Douche wrote:
> On Tue, Aug 16, 2011 at 13:45, Reinout van Rees<reinout at vanrees.org>  wrote:
>> >    recipe = zc.recipe.egg
> zc.recipe.egg can handle the new buildout options? When I want system
> packages I use z3.recipe.scripts :
> http://pypi.python.org/pypi/z3c.recipe.scripts/

I'm pretty sure zc.recipe.egg can, as it is bundled with buildout 
itself! But I *did* test out z3c.recipe.scripts and I had the same 
problem: buildout would try and build numpy from source.

And numpy for sure is installed (and osc.recipe.sysegg finds it just fine):

   $ python
   Python 2.6.6 (r266:84374, Aug 31 2010, 11:00:51)
   [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import numpy
   >>> numpy.__file__
 
'/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/__init__.pyc'


And my bin/buildout is:

   $ cat bin/buildout
 
#!/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python 
-S

   import sys
   sys.path[0:0] = [
       '/private/tmp/numpytest/parts/buildout',
       ]


   import os
   path = sys.path[0]
   if os.environ.get('PYTHONPATH'):
       path = os.pathsep.join([path, os.environ['PYTHONPATH']])
   os.environ['BUILDOUT_ORIGINAL_PYTHONPATH'] = 
os.environ.get('PYTHONPATH', '')
   os.environ['PYTHONPATH'] = path
   import site # imports custom buildout-generated site.py

   import zc.buildout.buildout

   if __name__ == '__main__':
       zc.buildout.buildout.main()


And just to make sure, here's my buildout.cfg:

   [buildout]
   parts = scripts
   include-site-packages = true
   allowed-eggs-from-site-packages =
       numpy

   [scripts]
   recipe = zc.recipe.egg
   eggs =
       numpy



Anyone spot anything suspicious?


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 madhav.bnk at gmail.com  Wed Aug 17 03:31:35 2011
From: madhav.bnk at gmail.com (B.Nanda Kishore)
Date: Wed, 17 Aug 2011 07:01:35 +0530
Subject: [Distutils] "buildout-versions" not showing pinned versions
In-Reply-To: <4E4A83D2.4050501@simplistix.co.uk>
References: <CAHheN2nh1Ndfa=RZZgP74tRRE2e=ANGS+15HFEUnWhW+y7u-fg@mail.gmail.com>
	<4E464069.9060401@simplistix.co.uk>
	<CAHheN2n0f=wkXPeyL=xOOPrpeMkKfs5vn6+8w34qcb=u54ym_g@mail.gmail.com>
	<4E4A83D2.4050501@simplistix.co.uk>
Message-ID: <CAHheN2n7xsR+YGwQjNA7Z8wjC1Ojti2JPZhkGmLQ+P=thtGBNQ@mail.gmail.com>

Its not just with Django. I have faced the same problem with a different
custom package
also. I have developed two sample packages(having just a setup.py with name
and version mentioned)
and I have tried installing both those packages using buildout. One of those
packages version number is pinned.
Here is the buildout.cfg

[buildout]
index=http://localhost:8000/
parts = deps
extensions = buildout-versions

[deps]
recipe = zc.recipe.egg
eggs = PkgA
            PkgB==0.1.0

When I ran the buildout, this is the output I got.

[versions]
PkgA = 0.1.0
buildout-versions = 1.6
distribute = 0.6.19
zc.buildout = 1.5.2
zc.recipe.egg = 1.3.2

Notice that PkgB's version is not printed. My doubt was regarding the
Line#33 in buildout-versions/__init__.py<https://github.com/Simplistix/buildout-versions/blob/master/src/buildout_versions/__init__.py#L33>.
That is the one which is filtering
the pinned distributions. I wanted to know why is it doing it ?

Regards,
Nandakishore


On Tue, Aug 16, 2011 at 8:20 PM, Chris Withers <chris at simplistix.co.uk>wrote:

> Hi,
>
> I've CC'ed in the correct mailing list for these discussions, you should
> mail there first in future.
>
> Right, replaying our discussion in it's original order:
>
>
> >     On 13/08/2011 04:04, B.Nanda Kishore wrote:
> >
> >         when my buildout.cfg is having content like:
> >         *[buildout]*
> >         *parts = deps*
> >         *extensions = buildout-versions*
> >         *
> >         *
> >         *[deps]*
> >         *recipe = zc.recipe.egg*
> >         *eggs = Django*
> >
> >         and when I run buildout its printing the latest Django
> version(1.3).
> >         Thats fine. But.....
> >         when I pin the version number of Django in buildout.cfg to
> something
>
> Okay, so it looks like you're pinning versions as follows:
>
>
> On 15/08/2011 06:20, B.Nanda Kishore wrote:
> > Here is my buildout.cfg:
> > [buildout]
> > parts = deps
> > extensions = buildout-versions
> >
> > [deps]
> > recipe = zc.recipe.egg
> > eggs = *Django==1.0.4*
>
> As an aside, I'll point out that the above buildout.cfg doesn't do anything
> useful as Django doesn't expose any setuptools-style console scripts.
>
> Now, buildout-versions won't report any versions here since you've pinned
> Django to 1.0.4. It only warns about un-pinned versions of eggs.
>
> Here's a minimal useful recipe that pins Django in a more orthodox fashion
> and provides a bin/py interpreter that will that version 1.0.4 of django
> available:
>
>
> [buildout]
> parts = deps
> extensions = buildout-versions
> versions = versions
>
>
> [versions]
> buildout-versions = 1.6
> Django = 1.0.4
> setuptools = 0.6c12dev-r88846
>
> zc.buildout = 1.5.2
> zc.recipe.egg = 1.3.2
>
> [deps]
> recipe = zc.recipe.egg
> eggs = Django
> interpreter = py
>
> However, I'd suggest looking at the djangorecipe package as a much more
> useful way of dealing with Django in buildout!
>
>
> cheers,
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
>            - http://www.simplistix.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110817/4d0f45ca/attachment.html>

From chris at simplistix.co.uk  Wed Aug 17 04:14:29 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 16 Aug 2011 19:14:29 -0700
Subject: [Distutils] "buildout-versions" not showing pinned versions
In-Reply-To: <CAHheN2n7xsR+YGwQjNA7Z8wjC1Ojti2JPZhkGmLQ+P=thtGBNQ@mail.gmail.com>
References: <CAHheN2nh1Ndfa=RZZgP74tRRE2e=ANGS+15HFEUnWhW+y7u-fg@mail.gmail.com>
	<4E464069.9060401@simplistix.co.uk>
	<CAHheN2n0f=wkXPeyL=xOOPrpeMkKfs5vn6+8w34qcb=u54ym_g@mail.gmail.com>
	<4E4A83D2.4050501@simplistix.co.uk>
	<CAHheN2n7xsR+YGwQjNA7Z8wjC1Ojti2JPZhkGmLQ+P=thtGBNQ@mail.gmail.com>
Message-ID: <4E4B2405.10102@simplistix.co.uk>

On 16/08/2011 18:31, B.Nanda Kishore wrote:
> [buildout]
> index=http://localhost:8000/
> parts = deps
> extensions = buildout-versions
>
> [deps]
> recipe = zc.recipe.egg
> eggs = PkgA
>              PkgB==0.1.0
>
> When I ran the buildout, this is the output I got.
>
> [versions]
> PkgA = 0.1.0
> buildout-versions = 1.6
> distribute = 0.6.19
> zc.buildout = 1.5.2
> zc.recipe.egg = 1.3.2
>
> Notice that PkgB's version is not printed.

Yes, as I said before, this is intended and will not change.

Here's an example buildout.cfg that shows why:

[buildout]
parts = part1 part2
extensions = buildout-versions
versions = versions

[versions]
SomePackage = 2.0

[part1]
recipe = zc.recipe.egg
eggs =
   SomePackage

[part2]
recipe = zc.recipe.egg
eggs =
   SomeOtherPackage
   SomePackage==1.0

To explain, SomeOtherPackage has a dependency on SomePackage, but hasn't 
been updated to work with version 2.0, so needs to be pinned to 1.0. 
However, the rest of the buildout is fine to use with the new version 2.0.

In general, buildout-versions should be used as described in its docs 
and versions should *only* be pinned in a [versions] section.

*Why* are you pinning in the eggs line?

cheers,

Chris

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

From chris at simplistix.co.uk  Wed Aug 17 04:23:34 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 16 Aug 2011 19:23:34 -0700
Subject: [Distutils] Which buildout to use?
In-Reply-To: <j2e3va$q95$1@dough.gmane.org>
References: <j2dl9d$m4t$1@dough.gmane.org>
	<CAAGHeXGFWojBDgcKXLzuwe1wgmNncRd80sgnoicbOzbQX_VVww@mail.gmail.com>
	<j2e3va$q95$1@dough.gmane.org>
Message-ID: <4E4B2626.20704@simplistix.co.uk>

On 16/08/2011 08:56, Reinout van Rees wrote:
> Anyone spot anything suspicious?

Maybe pin numpy to the version provided by the system?

Just a guess and nothing I've tried...

cheers,

Chris

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

From madhav.bnk at gmail.com  Wed Aug 17 05:32:03 2011
From: madhav.bnk at gmail.com (B.Nanda Kishore)
Date: Wed, 17 Aug 2011 09:02:03 +0530
Subject: [Distutils] "buildout-versions" not showing pinned versions
In-Reply-To: <4E4B2405.10102@simplistix.co.uk>
References: <CAHheN2nh1Ndfa=RZZgP74tRRE2e=ANGS+15HFEUnWhW+y7u-fg@mail.gmail.com>
	<4E464069.9060401@simplistix.co.uk>
	<CAHheN2n0f=wkXPeyL=xOOPrpeMkKfs5vn6+8w34qcb=u54ym_g@mail.gmail.com>
	<4E4A83D2.4050501@simplistix.co.uk>
	<CAHheN2n7xsR+YGwQjNA7Z8wjC1Ojti2JPZhkGmLQ+P=thtGBNQ@mail.gmail.com>
	<4E4B2405.10102@simplistix.co.uk>
Message-ID: <CAHheN2m-3ahjwVoKdQvg2fJex=WviJd6KsdmcFPv=RmGn3BJig@mail.gmail.com>

Well that was something new for me. Having two versions of the same package
in
the same buildout file.

Actually I was installing a few distributions in my workplace. So some
distros have
version pinned in their setup.py install_requires section, and when I run
the buildout
expecting the versions to be printed, its not printing those alone. So
mentioning the version
was not in the buildout file originally, but I see your point of putting
them in [versions] section.
But tell me this. In the above example(pinning a version number in
install_requires section of setup.py)
expecting the version of the package to be printed is a valid usecase right
? Is it not ? I know from the
example which you gave previously there seems to be some ambiguity from
which version to pick if
there are multiple versions. right ? Thats why its left out or ?

Regards,
Nandakishore


On Wed, Aug 17, 2011 at 7:44 AM, Chris Withers <chris at simplistix.co.uk>wrote:

> On 16/08/2011 18:31, B.Nanda Kishore wrote:
>
>> [buildout]
>> index=http://localhost:8000/
>> parts = deps
>> extensions = buildout-versions
>>
>> [deps]
>> recipe = zc.recipe.egg
>> eggs = PkgA
>>             PkgB==0.1.0
>>
>> When I ran the buildout, this is the output I got.
>>
>> [versions]
>> PkgA = 0.1.0
>> buildout-versions = 1.6
>> distribute = 0.6.19
>> zc.buildout = 1.5.2
>> zc.recipe.egg = 1.3.2
>>
>> Notice that PkgB's version is not printed.
>>
>
> Yes, as I said before, this is intended and will not change.
>
> Here's an example buildout.cfg that shows why:
>
> [buildout]
> parts = part1 part2
>
> extensions = buildout-versions
> versions = versions
>
> [versions]
> SomePackage = 2.0
>
> [part1]
>
> recipe = zc.recipe.egg
> eggs =
>  SomePackage
>
> [part2]
>
> recipe = zc.recipe.egg
> eggs =
>  SomeOtherPackage
>  SomePackage==1.0
>
> To explain, SomeOtherPackage has a dependency on SomePackage, but hasn't
> been updated to work with version 2.0, so needs to be pinned to 1.0.
> However, the rest of the buildout is fine to use with the new version 2.0.
>
> In general, buildout-versions should be used as described in its docs and
> versions should *only* be pinned in a [versions] section.
>
> *Why* are you pinning in the eggs line?
>
>
> cheers,
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
>            - http://www.simplistix.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110817/aece5918/attachment-0001.html>

From xordoquy at linovia.com  Wed Aug 17 08:16:14 2011
From: xordoquy at linovia.com (Xavier Ordoquy)
Date: Wed, 17 Aug 2011 08:16:14 +0200
Subject: [Distutils] Which buildout to use?
In-Reply-To: <4E4B2626.20704@simplistix.co.uk>
References: <j2dl9d$m4t$1@dough.gmane.org>
	<CAAGHeXGFWojBDgcKXLzuwe1wgmNncRd80sgnoicbOzbQX_VVww@mail.gmail.com>
	<j2e3va$q95$1@dough.gmane.org> <4E4B2626.20704@simplistix.co.uk>
Message-ID: <FF9F2F33-D300-4970-BA9E-AA6BF9CD4B6B@linovia.com>

Hi,

I'm didn't follow the full thread so I apologize if I'm off topic
If I remember correctly I had a couple of issues last year with numpy/ matplotlib and buildout because the two first weren't compliant with python packages.
I think numpy got python packaging compatibility for 1.5.0 so if your numpy's system wide installation is lower than that you most probably have no python package information hence

Regards,
Xavier.

From reinout at vanrees.org  Wed Aug 17 09:28:34 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Wed, 17 Aug 2011 09:28:34 +0200
Subject: [Distutils] Which buildout to use?
In-Reply-To: <FF9F2F33-D300-4970-BA9E-AA6BF9CD4B6B@linovia.com>
References: <j2dl9d$m4t$1@dough.gmane.org>
	<CAAGHeXGFWojBDgcKXLzuwe1wgmNncRd80sgnoicbOzbQX_VVww@mail.gmail.com>
	<j2e3va$q95$1@dough.gmane.org> <4E4B2626.20704@simplistix.co.uk>
	<FF9F2F33-D300-4970-BA9E-AA6BF9CD4B6B@linovia.com>
Message-ID: <j2fqj2$m2n$1@dough.gmane.org>

On 17-08-11 08:16, Xavier Ordoquy wrote:
> If I remember correctly I had a couple of issues last year with numpy/ matplotlib and buildout because the two first weren't compliant with python packages.
> I think numpy got python packaging compatibility for 1.5.0 so if your numpy's system wide installation is lower than that you most probably have no python package information hence

I've got 1.5.1 with a proper numpy-1.5.1-py2.6.egg-info directory in the 
site-packages.

But I also didn't trust numpy completely :-) , so I also did the tests 
with psycopg2: same result.


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 reinout at vanrees.org  Wed Aug 17 09:45:59 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Wed, 17 Aug 2011 09:45:59 +0200
Subject: [Distutils] Which buildout to use?
In-Reply-To: <4E4B2626.20704@simplistix.co.uk>
References: <j2dl9d$m4t$1@dough.gmane.org>
	<CAAGHeXGFWojBDgcKXLzuwe1wgmNncRd80sgnoicbOzbQX_VVww@mail.gmail.com>
	<j2e3va$q95$1@dough.gmane.org> <4E4B2626.20704@simplistix.co.uk>
Message-ID: <j2frjn$t6l$1@dough.gmane.org>

On 17-08-11 04:23, Chris Withers wrote:
> Maybe pin numpy to the version provided by the system?
>
> Just a guess and nothing I've tried...

*Partial hurray sound*

Actually... that works. If I pin numpy to 1.5.1, buildout uses my 
site-packages one! We're one step further!

Next hurdle: I don't want to pin that package, as I don't particularly 
care which numpy version it is as long as it is recent enough. If I pin 
1.5.12, it'll be fine on my OSX machine, but ubuntu probably has a 
slightly different version. And our webserver might be hanging one 
ubuntu version back.

So: is there a way to *force* buildout to use the site-packages one, 
regardless of the version? (Provided it matches some minimum version 
requirement in case I provided one, of course). I can't find it in the docs.

osc.recipe.sysegg has a "force-sysegg" option that does just that.



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 m.van.rees at zestsoftware.nl  Wed Aug 17 13:32:35 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Wed, 17 Aug 2011 13:32:35 +0200
Subject: [Distutils] "buildout-versions" not showing pinned versions
In-Reply-To: <CAHheN2m-3ahjwVoKdQvg2fJex=WviJd6KsdmcFPv=RmGn3BJig@mail.gmail.com>
References: <CAHheN2nh1Ndfa=RZZgP74tRRE2e=ANGS+15HFEUnWhW+y7u-fg@mail.gmail.com>
	<4E464069.9060401@simplistix.co.uk>
	<CAHheN2n0f=wkXPeyL=xOOPrpeMkKfs5vn6+8w34qcb=u54ym_g@mail.gmail.com>
	<4E4A83D2.4050501@simplistix.co.uk>
	<CAHheN2n7xsR+YGwQjNA7Z8wjC1Ojti2JPZhkGmLQ+P=thtGBNQ@mail.gmail.com>
	<4E4B2405.10102@simplistix.co.uk>
	<CAHheN2m-3ahjwVoKdQvg2fJex=WviJd6KsdmcFPv=RmGn3BJig@mail.gmail.com>
Message-ID: <4E4BA6D3.8040807@zestsoftware.nl>

Op 17-08-11 05:32, B.Nanda Kishore schreef:
> Well that was something new for me. Having two versions of the same
> package in
> the same buildout file.
>
> Actually I was installing a few distributions in my workplace. So some
> distros have
> version pinned in their setup.py install_requires section, and when I
> run the buildout
> expecting the versions to be printed, its not printing those alone. So
> mentioning the version
> was not in the buildout file originally, but I see your point of putting
> them in [versions] section.
> But tell me this. In the above example(pinning a version number in
> install_requires section of setup.py)
> expecting the version of the package to be printed is a valid usecase
> right ? Is it not ? I know from the
> example which you gave previously there seems to be some ambiguity from
> which version to pick if
> there are multiple versions. right ? Thats why its left out or ?

The goal of buildout-versions (or its cousin 
buildout.dumppickedversions) is to list all packages that are not 
pinned.   When a package is not pinned, buildout picks the most recent 
version.  That may work today and fail horribly tomorrow if this 
unpinned package is updated in backwards incompatible ways.

If buildout-versions prints anything I consider this an error in my 
buildout.  If I agree the correct versions have been picked I add the 
printed versions to the [versions] section, rerun the buildout and now 
buildout-versions should not print anything anymore.

In other words: buildout-versions does not print all versions, just the 
not-pinned ones that buildout has picked.  Like Chris said, this is 
intentional.


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


From fdrake at acm.org  Wed Aug 17 14:40:17 2011
From: fdrake at acm.org (Fred Drake)
Date: Wed, 17 Aug 2011 08:40:17 -0400
Subject: [Distutils] "buildout-versions" not showing pinned versions
In-Reply-To: <4E4B2405.10102@simplistix.co.uk>
References: <CAHheN2nh1Ndfa=RZZgP74tRRE2e=ANGS+15HFEUnWhW+y7u-fg@mail.gmail.com>
	<4E464069.9060401@simplistix.co.uk>
	<CAHheN2n0f=wkXPeyL=xOOPrpeMkKfs5vn6+8w34qcb=u54ym_g@mail.gmail.com>
	<4E4A83D2.4050501@simplistix.co.uk>
	<CAHheN2n7xsR+YGwQjNA7Z8wjC1Ojti2JPZhkGmLQ+P=thtGBNQ@mail.gmail.com>
	<4E4B2405.10102@simplistix.co.uk>
Message-ID: <CAFT4OTG313mzsz+zKhUWsUAs0vJ+dJ+1Egs1Ymp1irpBwLSzHQ@mail.gmail.com>

On Tue, Aug 16, 2011 at 10:14 PM, Chris Withers <chris at simplistix.co.uk> wrote:
> *Why* are you pinning in the eggs line?

At Zope, we've had to do this when different processes constructed by a build
had to use different versions of libraries.  buildout-versions aside, it's not
that unusual a case.


  -Fred

-- 
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A person who won't read has no advantage over one who can't read."
?? --Samuel Langhorne Clemens

From chris at simplistix.co.uk  Wed Aug 17 17:12:31 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 17 Aug 2011 08:12:31 -0700
Subject: [Distutils] "buildout-versions" not showing pinned versions
In-Reply-To: <CAFT4OTG313mzsz+zKhUWsUAs0vJ+dJ+1Egs1Ymp1irpBwLSzHQ@mail.gmail.com>
References: <CAHheN2nh1Ndfa=RZZgP74tRRE2e=ANGS+15HFEUnWhW+y7u-fg@mail.gmail.com>
	<4E464069.9060401@simplistix.co.uk>
	<CAHheN2n0f=wkXPeyL=xOOPrpeMkKfs5vn6+8w34qcb=u54ym_g@mail.gmail.com>
	<4E4A83D2.4050501@simplistix.co.uk>
	<CAHheN2n7xsR+YGwQjNA7Z8wjC1Ojti2JPZhkGmLQ+P=thtGBNQ@mail.gmail.com>
	<4E4B2405.10102@simplistix.co.uk>
	<CAFT4OTG313mzsz+zKhUWsUAs0vJ+dJ+1Egs1Ymp1irpBwLSzHQ@mail.gmail.com>
Message-ID: <4E4BDA5F.8000806@simplistix.co.uk>

On 17/08/2011 05:40, Fred Drake wrote:
> On Tue, Aug 16, 2011 at 10:14 PM, Chris Withers<chris at simplistix.co.uk>  wrote:
>> *Why* are you pinning in the eggs line?
>
> At Zope, we've had to do this when different processes constructed by a build
> had to use different versions of libraries.  buildout-versions aside, it's not
> that unusual a case.

Indeed, I believe I did explain that usecase ;-)

Myself, I'd just use multiple buildouts, and I don't think I've ever 
bumped into the situation you're describing, but nonetheless, if you've 
pinned the version some other way, then buildout-versions won't tell you 
that it hasn't been pinned...

cheers,

Chris

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

From chris at simplistix.co.uk  Wed Aug 17 17:16:59 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 17 Aug 2011 08:16:59 -0700
Subject: [Distutils] "buildout-versions" not showing pinned versions
In-Reply-To: <CAHheN2m-3ahjwVoKdQvg2fJex=WviJd6KsdmcFPv=RmGn3BJig@mail.gmail.com>
References: <CAHheN2nh1Ndfa=RZZgP74tRRE2e=ANGS+15HFEUnWhW+y7u-fg@mail.gmail.com>
	<4E464069.9060401@simplistix.co.uk>
	<CAHheN2n0f=wkXPeyL=xOOPrpeMkKfs5vn6+8w34qcb=u54ym_g@mail.gmail.com>
	<4E4A83D2.4050501@simplistix.co.uk>
	<CAHheN2n7xsR+YGwQjNA7Z8wjC1Ojti2JPZhkGmLQ+P=thtGBNQ@mail.gmail.com>
	<4E4B2405.10102@simplistix.co.uk>
	<CAHheN2m-3ahjwVoKdQvg2fJex=WviJd6KsdmcFPv=RmGn3BJig@mail.gmail.com>
Message-ID: <4E4BDB6B.1020309@simplistix.co.uk>

On 16/08/2011 20:32, B.Nanda Kishore wrote:
> Actually I was installing a few distributions in my workplace. So some
> distros have
> version pinned in their setup.py install_requires section,

This is pretty evil. Why on earth are you doing this?
You should only ever place version limits in install_requires, and even 
then, only if there are compatibility issues with a library a package 
depends on.

eg: install_requries=['SomePackage < 2.0']

> and when I
> run the buildout
> expecting the versions to be printed,

For the third time, why are you expecting versions to be printed here?
You've pinned the version required, so buildout-versions won't report it 
as unpinned...

> But tell me this. In the above example(pinning a version number in
> install_requires section of setup.py)
> expecting the version of the package to be printed is a valid usecase
> right ?

Wrong.

> Is it not ?

No, it is not.

cheers,

Chris

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

From lists at asheesh.org  Thu Aug 18 17:34:06 2011
From: lists at asheesh.org (Asheesh Laroia)
Date: Thu, 18 Aug 2011 11:34:06 -0400
Subject: [Distutils] [PATCH] Letting distribute try different download URLs
Message-ID: <1313681375-sup-2732@rose.makesad.us>

Hi all,

I have a very real-world problem I'm hitting with distribute, and I'm
proposing a patch.

Right now, PyPI points to a tar.gz for the 'nose' package that returns

    Searching for nose==1.0.0
    Reading http://pypi.python.org/simple/nose/
    Reading http://somethingaboutorange.com/mrl/projects/nose/
    Reading http://readthedocs.org/docs/nose/
    Best match: nose 1.0.0
    Downloading http://somethingaboutorange.com/mrl/projects/nose/nose-1.0.0.tar.gz
    error: Can't download http://somethingaboutorange.com/mrl/projects/nose/nose-1.0.0.tar.gz: 404 Not Found

I propose that if distribute hits a HTTP error like this, it keeps looping and
tries the next available tar.gz for nose. In my case, I think it then succeed
because I have dependency_links in my setup() call (in my setup.py) that point
to where I have been stashing copies of my own dependencies:

   http://linode.openhatch.org/~paulproteus/

So I propose this patch. It is pretty straightforward. I hope that you accept
it, and if not, that you explain why.

I have re-run the test suite after the addition of my patch, and it does not
break any existing tests.

-- Asheesh.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: distribute-patch-to-try-other-urls.patch
Type: application/octet-stream
Size: 1648 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110818/8e549217/attachment.obj>

From utebachmeier at gmail.com  Thu Aug 18 22:36:50 2011
From: utebachmeier at gmail.com (Sabrina Friedman)
Date: Thu, 18 Aug 2011 23:36:50 +0300
Subject: [Distutils] [Python Language Summit] Distutils / Packaging
	surveyfrom Sabrina
Message-ID: <CAJmcYhbvK2nLgv65isDmvmjWzSS2s-J0k8-75jm_387EtFSMEg@mail.gmail.com>

On Sat, 31 Jan 2009 10:37:56 -0500, "P.J. Eby" <pje at telecommunity.com>
wrote:

> If this is true, then there's no need to distinguish between .py
> files and any other data files - they both belong in /share to begin
> with, not in /lib.  Or else they ALL belong in /lib.  The entire "FHS
> demands they be split" concept is wrong from the get-go, under that
> interpretation.

Not taking away from that....

but in windows things have their own directories too and python
files should go in the right places also.

Best place for packages -> \Program Files\Common Files\Python x.x\Packages

Best place for python -> \Program Files\Python x.x

Under linux - Best place for packages -> /usr/local/Python x.x/Packages.

(a python developer shouldn't go looking in system directories for
a source package he may want to look at)

Putting files where people expect to find them, doesn't cost more. The
only reason things are the way they are is because of history. But at
the same time, if we want our software to "live" in an operating system
we must follow their rules to be regarded as good citizens.

:-)

Regards

David



Sabrina Friedman
Billige Fl?ge Marketing GmbH
Emanuelstr. 3,
10317 Berlin
Deutschland
Telefon: +49 (33) 5310967
Email: utebachmeier at gmail.com
Site: http://flug.airego.de - Billige Fl?ge vergleichen

From quasipedia at gmail.com  Fri Aug 19 15:43:03 2011
From: quasipedia at gmail.com (Mac Ryan)
Date: Fri, 19 Aug 2011 15:43:03 +0200
Subject: [Distutils] Dependency problems.
Message-ID: <20110819154303.1d064596@jabbar>

Hello,

	I just subscribed yesterday, having being redirected here from
the python-tutor ML. I hope this is the right place to ask the question
I am struggling with.

	I am trying to package a program I wrote for debian. It's my
**very first time** with packaging at all, and also with distutils, so
I followed online documentation to get something done. It work-ish'ed,
but I am struggling with a problem on dependencies.

	To write my setup.py script I followed this:
http://packages.python.org/distribute/setuptools.html#automatic-script-creation

	In the section on dependencies it says: "If your project
depends on packages that aren?t registered in PyPI, you	may
still be able to depend on them, as long as they are available for
download as an egg, in the standard distutils sdist format, or as a
single .py file. You just need to add some URLs to the dependency_links
argument to setup()."

	My question is: how do I list dpendencies that are not python
code? For example: say my program needs to launch at some point another
program like for example inkscape, is there a way to specify this in
the setup.py file, or am I out of luck and my only chance is to list it
in the debian directory half-way through the process of converting my
code to a .deb package?

	Also, another question out of scientific curiosity. On a
debian-based distro, if a python module is installed via PyPI, will it
be "seen" and handled by apt-get / synaptic as if it were installed
from a .deb package? In other words: would a user be able to execute
`apt-get remove xxxx` if xxxx has been installed with python
easy_install xxxx`?

	Thank you in advance for your help!
	/mac

From m.van.rees at zestsoftware.nl  Fri Aug 19 16:11:29 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Fri, 19 Aug 2011 16:11:29 +0200
Subject: [Distutils] Dependency problems.
In-Reply-To: <20110819154303.1d064596@jabbar>
References: <20110819154303.1d064596@jabbar>
Message-ID: <j2lqui$sgi$1@dough.gmane.org>

Hello Mac,

Op 19-08-11 15:43, Mac Ryan schreef:
> Hello,
>
> 	I just subscribed yesterday, having being redirected here from
> the python-tutor ML. I hope this is the right place to ask the question
> I am struggling with.
>
> 	I am trying to package a program I wrote for debian. It's my
> **very first time** with packaging at all, and also with distutils, so
> I followed online documentation to get something done. It work-ish'ed,
> but I am struggling with a problem on dependencies.
>
> 	To write my setup.py script I followed this:
> http://packages.python.org/distribute/setuptools.html#automatic-script-creation
>
> 	In the section on dependencies it says: "If your project
> depends on packages that aren?t registered in PyPI, you	may
> still be able to depend on them, as long as they are available for
> download as an egg, in the standard distutils sdist format, or as a
> single .py file. You just need to add some URLs to the dependency_links
> argument to setup()."
>
> 	My question is: how do I list dpendencies that are not python
> code? For example: say my program needs to launch at some point another
> program like for example inkscape, is there a way to specify this in
> the setup.py file, or am I out of luck and my only chance is to list it
> in the debian directory half-way through the process of converting my
> code to a .deb package?

The text you find is still talking about python packages.  It means: 
when you depend on python packages that are not registered on PyPI, you 
can use the dependency_links argument.

It will not work for inkscape.

As an example, when I need some ldap integration then in my setup.py I 
can list python-ldap as a dependency.  This python package will then be 
installed.  But that python-ldap package itself will fail to install 
when you do not have the necessary ldap bindings installed on your OS 
(it would fail in the compile step then, hopefully with a clear error 
message).  There is no way that I know for the python-ldap package to 
declare such an OS-dependency.


> 	Also, another question out of scientific curiosity. On a
> debian-based distro, if a python module is installed via PyPI, will it
> be "seen" and handled by apt-get / synaptic as if it were installed
> from a .deb package? In other words: would a user be able to execute
> `apt-get remove xxxx` if xxxx has been installed with python
> easy_install xxxx`?

No, sorry, that won't work.  The two are completely separate.

> 	Thank you in advance for your help!
> 	/mac

You're welcome.

Cheers,


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


From quasipedia at gmail.com  Mon Aug 22 03:30:33 2011
From: quasipedia at gmail.com (Mac Ryan)
Date: Mon, 22 Aug 2011 03:30:33 +0200
Subject: [Distutils] Crying over "data_files".
In-Reply-To: <j2lqui$sgi$1@dough.gmane.org>
References: <20110819154303.1d064596@jabbar>
	<j2lqui$sgi$1@dough.gmane.org>
Message-ID: <20110822033033.124f1e54@jabbar>

Hello,

	thanks also to the feedback of this ML members, I manage to get
going with debian packages using distutils + setuptools + stdeb.
There are a few things that still puzzle me though on the data_files
parameter of the setup script.

The need for a MANIFEST.in file
-------------------------------
Apparently including the list of files in `data_files` is not
sufficient for them to be included in the distribution. I found this
question on StackOverflow: http://stackoverflow.com/q/2994396/146792
and the accepted answer states that it was a bug fixed in python 2.7.
(most probably this one: http://bugs.python.org/issue2279). Although I
am running ubuntu 11.04 (shipping python 2.7.1+) the behaviour for me is
still the old, possibly buggy one. What am I doing wrong?

Data files for modules (instead than for packages)
--------------------------------------------------
The small application I am testing my packaging skills with, has a file
structure like this:

.
??? distribute_setup.py
??? MANIFEST.in
??? setup.py
??? src
    ??? prog.py
    ??? scrapedata.py
    ??? data.yml

In my distribution I only want to ship `prog.py` and `data.yml`,
ignoring `scrapedata.py`. Initially I managed to build the .deb package
by creating an `__init__.py`  file in the `src` directory and then
putting in my setup.py something like:

    packages = find_packages(),
    package_data = {'src': ['data.yml'],

but then I realised that doing so I was creating a `src` directory
under `/usr/lib/python2.7/dist-packages`, which seems very wrong (src
is just a directory for me to keep my files organised, it is not a
package). So I tried to do something like:

    py_modules = ['src/prog'],
    data_files=['', ['src/data.yml']],

but - beside not working (see following question) - I wonder if there
is a standard and better way to link data files to specific modules
rather than packages.

The dreadful "error: can't copy '': doesn't exist or not a regular file"
------------------------------------------------------------------------
This actually happens when I try to assemble the built distribution for
debian (so it the problem might be with stdeb rather than with
distutils, but I'm unsure). In my setup script I have:

    data_files=['', ['src/data.yml']],

If I alter the destination directory with for example '.', the error
message will be the same, just reporting the '.' instead of the
'' (this is why I am sure it is related to this line)... Again, I am a
bit confused... am I doing something wrong here?

Thank you in advance for your help (and sorry if I am asking something
silly. This is my very first experience with distutils and packaging! :)

/mac

From quasipedia at gmail.com  Mon Aug 22 14:21:30 2011
From: quasipedia at gmail.com (Mac Ryan)
Date: Mon, 22 Aug 2011 14:21:30 +0200
Subject: [Distutils] stdeb bug?
Message-ID: <20110822142130.32ea371f@jabbar>

After having wasted some more hours in trying to understand why I can't
package data_files in the same directory of the python modules (see my
previous post to the ML) I begin to believe I might have hit a bug in
stdeb...

In fact the setup.py script that I wrote works fine with

	python setup.py sdist

(the tar.gz that is being generated has both my module and data file in
the same directory) but it throws errors when I run:

	python setup.py --command-packages=stdeb.command bdist_deb

specifically it says:

	warning: install_data: setup script did not provide a directory
	for '' -- installing right in
	'/home/<mydirectory>/debian/python-<myapplicationname>/usr'
	error: can't copy '': doesn't exist or not a regular file

in my setup.py:

	py_modules = ['src/prog'],
	data_files=['', ['src/data.yml']],

so I believe stdeb is simply unable to understand that the empty string
means "put the data file together with the module", the way the regular
distutils can.

Am I right? Any workaround to suggest?

Thank you in advance,
/mac

From eposse at gmail.com  Mon Aug 22 21:03:50 2011
From: eposse at gmail.com (Ernesto Posse)
Date: Mon, 22 Aug 2011 15:03:50 -0400
Subject: [Distutils] Dependency problems.
In-Reply-To: <j2lqui$sgi$1@dough.gmane.org>
References: <20110819154303.1d064596@jabbar>
	<j2lqui$sgi$1@dough.gmane.org>
Message-ID: <CABY2naxGX_pxDM8nqwFvHWukojO+1mWx6YMZ5p3v76KE+OvB3g@mail.gmail.com>

On Fri, Aug 19, 2011 at 10:11 AM, Maurits van Rees
<m.van.rees at zestsoftware.nl> wrote:
> Hello Mac,
>
> Op 19-08-11 15:43, Mac Ryan schreef:
>>
>> ? ? ? ?Also, another question out of scientific curiosity. On a
>> debian-based distro, if a python module is installed via PyPI, will it
>> be "seen" and handled by apt-get / synaptic as if it were installed
>> from a .deb package? In other words: would a user be able to execute
>> `apt-get remove xxxx` if xxxx has been installed with python
>> easy_install xxxx`?
>
> No, sorry, that won't work. ?The two are completely separate.
>

If you are interested in packaging for debian, lookup "stdeb" on PyPI.
It will allow you to generate .deb packages which can be installed and
handled by apt-get/synaptic.


-- 
Ernesto Posse

Modelling and Analysis in Software Engineering
School of Computing
Queen's University - Kingston, Ontario, Canada

From quasipedia at gmail.com  Mon Aug 22 22:42:37 2011
From: quasipedia at gmail.com (Mac Ryan)
Date: Mon, 22 Aug 2011 22:42:37 +0200
Subject: [Distutils] Dependency problems.
In-Reply-To: <CABY2naxGX_pxDM8nqwFvHWukojO+1mWx6YMZ5p3v76KE+OvB3g@mail.gmail.com>
References: <20110819154303.1d064596@jabbar> <j2lqui$sgi$1@dough.gmane.org>
	<CABY2naxGX_pxDM8nqwFvHWukojO+1mWx6YMZ5p3v76KE+OvB3g@mail.gmail.com>
Message-ID: <20110822224237.4e20186e@jabbar>

On Mon, 22 Aug 2011 15:03:50 -0400
Ernesto Posse <eposse at gmail.com> wrote:

> If you are interested in packaging for debian, lookup "stdeb" on PyPI.
> It will allow you to generate .deb packages which can be installed and
> handled by apt-get/synaptic.

Thank you Ernesto, just wondering if the other message that I sent to
earlier today to the ML arrived, as I was in fact speaking of a
possible bug in stdeb...

/mac

From reinout at vanrees.org  Tue Aug 23 16:45:30 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Tue, 23 Aug 2011 16:45:30 +0200
Subject: [Distutils] Dependency problems.
In-Reply-To: <20110822224237.4e20186e@jabbar>
References: <20110819154303.1d064596@jabbar> <j2lqui$sgi$1@dough.gmane.org>
	<CABY2naxGX_pxDM8nqwFvHWukojO+1mWx6YMZ5p3v76KE+OvB3g@mail.gmail.com>
	<20110822224237.4e20186e@jabbar>
Message-ID: <j30eea$auk$1@dough.gmane.org>

On 22-08-11 22:42, Mac Ryan wrote:
> Thank you Ernesto, just wondering if the other message that I sent to
> earlier today to the ML arrived, as I was in fact speaking of a
> possible bug in stdeb...

I've seen that one, so it arrived just fine on the list.


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 vladik.rikhter at gmail.com  Wed Aug 24 07:29:06 2011
From: vladik.rikhter at gmail.com (Vladik Rikhter)
Date: Tue, 23 Aug 2011 22:29:06 -0700
Subject: [Distutils] Having trouble with pip install
Message-ID: <CAEp0G7x4t9Fyio_j2h48qotcZeAr+zQ-SztZNZ_qUsS7+Br_sQ@mail.gmail.com>

Hi (excuse the n00b like question, but I'm lost at this point):

I've been trying to install my requirements.txt file with pip through
Cygwin.  I went through and ran the easy_install, worked without a problem.
 I then tried to execute the following command:
"pip install -r requirements.txt"

Unfortunately the following error came up:

> Downloading/unpacking git+http://github.com/tropo/tropo-webapi-python.git(from
> -r requirements.txt (line 9))
>   Cloning http://github.com/tropo/tropo-webapi-python.git to
> /tmp/pip-E3epk3-bui
> ld
>   Running setup.py egg_info for package from git+
> http://github.com/tropo/tropo-w
> ebapi-python.git
>       1 [main] python2.6 9848 C:\cygwin\bin\python2.6.exe: *** fatal error
> - una
> ble to remap \\?\C:\cygwin\lib\python2.6\lib-dynload\time.dll to same
> address as
>  parent: 0x360000 != 0x3F0000
> Stack trace:
> Frame     Function  Args
> 00289F08  6102796B  (00289F08, 00000000, 00000000, 00000000)
> 0028A1F8  6102796B  (6117EC60, 00008000, 00000000, 61180977)
> 0028B228  61004F1B  (611A7FAC, 61243884, 00360000, 003F0000)
> End of stack trace
>       1 [main] python2.6 11796 fork: child 9848 - died waiting for dll
> loading,
> errno 11
>     Error [Errno 11] Resource temporarily unavailable while executing
> command py
> thon setup.py egg_info
> Exception:
> Traceback (most recent call last):
>   File
> "/usr/lib/python2.6/site-packages/pip-1.0.2-py2.6.egg/pip/basecommand.py"
> , line 126, in main
>     self.run(options, args)
>   File
> "/usr/lib/python2.6/site-packages/pip-1.0.2-py2.6.egg/pip/commands/instal
> l.py", line 223, in run
>     requirement_set.prepare_files(finder, force_root_egg_info=self.bundle,
> bundl
> e=self.bundle)
>   File "/usr/lib/python2.6/site-packages/pip-1.0.2-py2.6.egg/pip/req.py",
> line 9
> 86, in prepare_files
>     req_to_install.run_egg_info()
>   File "/usr/lib/python2.6/site-packages/pip-1.0.2-py2.6.egg/pip/req.py",
> line 2
> 22, in run_egg_info
>     command_desc='python setup.py egg_info')
>   File
> "/usr/lib/python2.6/site-packages/pip-1.0.2-py2.6.egg/pip/__init__.py", l
> ine 220, in call_subprocess
>     cwd=cwd, env=env)
>   File "/usr/lib/python2.6/subprocess.py", line 633, in __init__
>     errread, errwrite)
>   File "/usr/lib/python2.6/subprocess.py", line 1049, in _execute_child
>     self.pid = os.fork()
> OSError: [Errno 11] Resource temporarily unavailable
> Storing complete log in /home/Vladik/.pip/pip.log


Would love some help on how to fix this! Thank you, thank you!
--
(c) 404.966.9048
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110823/34ecddbd/attachment.html>

From matthew.brett at gmail.com  Fri Aug 26 03:06:48 2011
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 25 Aug 2011 18:06:48 -0700
Subject: [Distutils] Specify missing install-requires dependencies to
	develop egg?
Message-ID: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>

Hi,

We have been working on using buildout with a develop package
depending on numpy, and ran into trouble because 'numpy' is not
specified in the package 'install_requires'.

Specifically, we have something like this:

[buildout]
parts =
    nibabel-target
    mypy

[nibabel-target]
recipe = zc.recipe.egg:develop
setup = src/nibabel

[mypy]
recipe = zc.recipe.egg:script
eggs =
    nibabel
interpreter = py

'nibabel' needs to import numpy to install, but does not specify
'numpy' in its setup.py install_requires, because pip install of numpy
is fragile, and we wanted to error early in general for an attempted
pip install of nibabel, if numpy was not present.

But of course the script above raises an error for the
'nibabel-target' part, because of missing numpy:

-------------
RuntimeError: Cannot import package "numpy" - is it installed?
While:
  Installing nibabel-target.

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
------------

What we would very much like to do, is to be able to specify the
missing install_requires for this package (and for others we are
thinking of working with), in the recipe - something like:

[nibabel-target]
recipe = zc.recipe.egg:develop
setup = src/nibabel
install-requires =
    numpy

but we couldn't immediately see a way of specifying such a dependency.
  A quick look at the Develop code in zc/recipe/egg/custom.py
suggested that there wasn't an easy way to add some needed egg onto
the path at this point.

Is there anything we missed that we should have tried?

If not, what would be the best way to solve our problem?  A modified recipe?

Best,

Matthew

From reinout at vanrees.org  Fri Aug 26 04:06:47 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Fri, 26 Aug 2011 04:06:47 +0200
Subject: [Distutils] Specify missing install-requires dependencies to
	develop egg?
In-Reply-To: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
References: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
Message-ID: <j36v3n$dv5$1@dough.gmane.org>

On 26-08-11 03:06, Matthew Brett wrote:
> [mypy]
> recipe = zc.recipe.egg:script
> eggs =
>      nibabel
> interpreter = py
>
...
>
> What we would very much like to do, is to be able to specify the
> missing install_requires for this package (and for others we are
> thinking of working with)

The solution is quite simple: just add numpy to the list of eggs like this:

[mypy]
recipe = zc.recipe.egg:script
eggs =
     nibabel
     numpy
interpreter = py




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 matthew.brett at gmail.com  Fri Aug 26 04:20:07 2011
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 25 Aug 2011 19:20:07 -0700
Subject: [Distutils] Specify missing install-requires dependencies to
 develop egg?
In-Reply-To: <j36v3n$dv5$1@dough.gmane.org>
References: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
	<j36v3n$dv5$1@dough.gmane.org>
Message-ID: <CAH6Pt5peuWK02MhDEWzvJaznfzYMiohtcOz5o=PEhsBGkzhkaw@mail.gmail.com>

Hi,

On Thu, Aug 25, 2011 at 7:06 PM, Reinout van Rees <reinout at vanrees.org> wrote:
> On 26-08-11 03:06, Matthew Brett wrote:
>>
>> [mypy]
>> recipe = zc.recipe.egg:script
>> eggs =
>> ? ? nibabel
>> interpreter = py
>>
> ...
>>
>> What we would very much like to do, is to be able to specify the
>> missing install_requires for this package (and for others we are
>> thinking of working with)
>
> The solution is quite simple: just add numpy to the list of eggs like this:
>
> [mypy]
> recipe = zc.recipe.egg:script
> eggs =
> ? ?nibabel
> ? ?numpy
> interpreter = py

That doesn't work for me. Rightly or wrongly I am guessing that the
problem is that the dependency is not for the interpreter, but for
running nibabel setup.py.  In any case the failure remains with that
addition:

Updating nibabel-target.
Traceback (most recent call last):
  File "/tmp/tmpnKAmK6", line 11, in <module>
    execfile('/home/mb312/tmp/buildbotting/src/nibabel/setup.py')
  File "/home/mb312/tmp/buildbotting/src/nibabel/setup.py", line 40, in <module>
    package_check('numpy', NUMPY_MIN_VERSION)
  File "/home/mb312/tmp/buildbotting/src/nibabel/nisext/sexts.py",
line 122, in package_check
    raise RuntimeError(msgs['missing'] % pkg_name)
RuntimeError: Cannot import package "numpy" - is it installed?
While:
  Updating nibabel-target.

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
...

Best,

Matthew

From reinout at vanrees.org  Fri Aug 26 04:25:27 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Fri, 26 Aug 2011 04:25:27 +0200
Subject: [Distutils] Specify missing install-requires dependencies to
	develop egg?
In-Reply-To: <CAH6Pt5peuWK02MhDEWzvJaznfzYMiohtcOz5o=PEhsBGkzhkaw@mail.gmail.com>
References: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
	<j36v3n$dv5$1@dough.gmane.org>
	<CAH6Pt5peuWK02MhDEWzvJaznfzYMiohtcOz5o=PEhsBGkzhkaw@mail.gmail.com>
Message-ID: <j3706n$l94$1@dough.gmane.org>

On 26-08-11 04:20, Matthew Brett wrote:
>>> What we would very much like to do, is to be able to specify the
>>> >>  missing install_requires for this package (and for others we are
>>> >>  thinking of working with)
>> >
>> >  The solution is quite simple: just add numpy to the list of eggs like this:
>> >
>> >  [mypy]
>> >  recipe = zc.recipe.egg:script
>> >  eggs =
>> >      nibabel
>> >      numpy
>> >  interpreter = py
> That doesn't work for me. Rightly or wrongly I am guessing that the
> problem is that the dependency is not for the interpreter, but for
> running nibabel setup.py.  In any case the failure remains with that
> addition:
>
> Updating nibabel-target.
> Traceback (most recent call last):
>    File "/tmp/tmpnKAmK6", line 11, in<module>
>      execfile('/home/mb312/tmp/buildbotting/src/nibabel/setup.py')
>    File "/home/mb312/tmp/buildbotting/src/nibabel/setup.py", line 40, in<module>
>      package_check('numpy', NUMPY_MIN_VERSION)
>    File "/home/mb312/tmp/buildbotting/src/nibabel/nisext/sexts.py",
> line 122, in package_check
>      raise RuntimeError(msgs['missing'] % pkg_name)
> RuntimeError: Cannot import package "numpy" - is it installed?
> While:
>    Updating nibabel-target.

"Updating nibabel-target": that's not the same part as that "mypy" 
target. Note that such an eggs attribute is only valid for that one part.

So "[nibabel-target]" also should have an eggs attribute with numpy in it.

Perhaps handier: add an "eggs" attribute to [buildout] with nibabel and 
numpy in it and use that:

[buildout]
....
eggs =
     nibabel
     numpy

[mypy]
...
eggs = ${buildout:eggs}
...

[nibabel]
...
eggs = ${buildout:eggs}
...



DOes that work?



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 reinout at vanrees.org  Fri Aug 26 04:50:23 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Fri, 26 Aug 2011 04:50:23 +0200
Subject: [Distutils] Specify missing install-requires dependencies to
	develop egg?
In-Reply-To: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
References: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
Message-ID: <j371lf$rj3$1@dough.gmane.org>

On 26-08-11 03:06, Matthew Brett wrote:
> 'nibabel' needs to import numpy to install

With your latest reply I re-read your original. Hm, this looks like a 
real problem: if your setup.py already imports from numpy (which your 
statement sounds like), numpy really needs to be there already.

The only thing I can think of right now is to have numpy installed 
globally and to use buildout 1.4.4 + osc.recipe.sysegg to depend on 
numpy. If you call the sysegg part right at the beginning, you might get 
it to work.


Alternative is to re-work your setup.py. Do you really need to import numpy?


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 matthew.brett at gmail.com  Fri Aug 26 05:10:04 2011
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 25 Aug 2011 20:10:04 -0700
Subject: [Distutils] Specify missing install-requires dependencies to
 develop egg?
In-Reply-To: <j371lf$rj3$1@dough.gmane.org>
References: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
	<j371lf$rj3$1@dough.gmane.org>
Message-ID: <CAH6Pt5oXAByWzNK1Ea9Tnb_M-TXtKBZk=ZS1KWkSdKvv7aEFJg@mail.gmail.com>

Hi,

On Thu, Aug 25, 2011 at 7:50 PM, Reinout van Rees <reinout at vanrees.org> wrote:
> On 26-08-11 03:06, Matthew Brett wrote:
>>
>> 'nibabel' needs to import numpy to install
>
> With your latest reply I re-read your original. Hm, this looks like a real
> problem: if your setup.py already imports from numpy (which your statement
> sounds like), numpy really needs to be there already.

Yes, that is what made me think that a new recipe might be the only
way, where the recipe would put numpy on the path during the develop
step.

> The only thing I can think of right now is to have numpy installed globally
> and to use buildout 1.4.4 + osc.recipe.sysegg to depend on numpy. If you
> call the sysegg part right at the beginning, you might get it to work.

Yes, if numpy is already on the path, it works, but we wanted to test
against several different numpy versions, and it seemed ugly and
fragile to make a separate virtualenv for each python / numpy version
pair.  We'd much rather use the buildout mechanism to specify these,
if possible.

> Alternative is to re-work your setup.py. Do you really need to import numpy?

Actually, no, not in this case, it is only used as a crude dependency
check.  But, for other packages we have, we do need numpy.distutils
for the setup.py - for example to find the numpy include directory for
compiling C modules.  The only reason I was offering this package as
an example is that it is rather small and easy to install compared to
the others.

Thanks a lot,

Matthew

From jim at zope.com  Fri Aug 26 15:05:42 2011
From: jim at zope.com (Jim Fulton)
Date: Fri, 26 Aug 2011 09:05:42 -0400
Subject: [Distutils] Specify missing install-requires dependencies to
 develop egg?
In-Reply-To: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
References: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
Message-ID: <CAPDm-FgwjyU31eeg4sDFyTdfHrrmMvmM7xCZrB5Y2pJ0GR6W4A@mail.gmail.com>

On Thu, Aug 25, 2011 at 9:06 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> We have been working on using buildout with a develop package
> depending on numpy, and ran into trouble because 'numpy' is not
> specified in the package 'install_requires'.
>
> Specifically, we have something like this:
>
> [buildout]
> parts =
> ? ?nibabel-target
> ? ?mypy
>
> [nibabel-target]
> recipe = zc.recipe.egg:develop
> setup = src/nibabel
>
> [mypy]
> recipe = zc.recipe.egg:script
> eggs =
> ? ?nibabel
> interpreter = py
>
> 'nibabel' needs to import numpy to install, but does not specify
> 'numpy' in its setup.py install_requires, because pip install of numpy
> is fragile, and we wanted to error early in general for an attempted
> pip install of nibabel, if numpy was not present.
>
> But of course the script above raises an error for the
> 'nibabel-target' part, because of missing numpy:
>
> -------------
> RuntimeError: Cannot import package "numpy" - is it installed?
> While:
> ?Installing nibabel-target.
>
> An internal error occurred due to a bug in either zc.buildout or in a
> recipe being used:
> ------------
>
> What we would very much like to do, is to be able to specify the
> missing install_requires for this package (and for others we are
> thinking of working with), in the recipe - something like:
>
> [nibabel-target]
> recipe = zc.recipe.egg:develop
> setup = src/nibabel
> install-requires =
> ? ?numpy
>
> but we couldn't immediately see a way of specifying such a dependency.
> ?A quick look at the Develop code in zc/recipe/egg/custom.py
> suggested that there wasn't an easy way to add some needed egg onto
> the path at this point.
>
> Is there anything we missed that we should have tried?
>
> If not, what would be the best way to solve our problem? ?A modified recipe?

Theoretically, you'd use setup_requires to specify packages needed by setup.
I'm not sure if that works with buildout. I've heard reports that it
does and reports that
it doesn't.

Why does nibabel want numpy at setup time? If it's to get C incluse files, then
you may be out of luck, as it's unlikely that buildout will install
numpy in a way that
will give nibabel what it wants.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton

From wichert at wiggy.net  Fri Aug 26 15:17:55 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Fri, 26 Aug 2011 15:17:55 +0200
Subject: [Distutils] Specify missing install-requires dependencies to
 develop egg?
In-Reply-To: <4E579C9D.2070606@wiggy.net>
References: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
	<CAPDm-FgwjyU31eeg4sDFyTdfHrrmMvmM7xCZrB5Y2pJ0GR6W4A@mail.gmail.com>
	<4E579C9D.2070606@wiggy.net>
Message-ID: <4E579D03.20206@wiggy.net>

On 08/26/2011 03:16 PM, Wichert Akkerman wrote:
> On 08/26/2011 03:05 PM, Jim Fulton wrote:
>> Theoretically, you'd use setup_requires to specify packages needed by 
>> setup.
>> I'm not sure if that works with buildout. I've heard reports that it
>> does and reports that
>> it doesn't.
>
> I'm pretty sure it doesn't. There is an open bug for it: 
> https://bugs.launchpad.net/zc.buildout/+bug/257555 . This bug looks 
> related: https://bugs.launchpad.net/zc.buildout/+bug/110133 .

https://bugs.launchpad.net/zc.buildout/+bug/325658 is interesting as well.

Wichert.


From wichert at wiggy.net  Fri Aug 26 15:16:13 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Fri, 26 Aug 2011 15:16:13 +0200
Subject: [Distutils] Specify missing install-requires dependencies to
 develop egg?
In-Reply-To: <CAPDm-FgwjyU31eeg4sDFyTdfHrrmMvmM7xCZrB5Y2pJ0GR6W4A@mail.gmail.com>
References: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
	<CAPDm-FgwjyU31eeg4sDFyTdfHrrmMvmM7xCZrB5Y2pJ0GR6W4A@mail.gmail.com>
Message-ID: <4E579C9D.2070606@wiggy.net>

On 08/26/2011 03:05 PM, Jim Fulton wrote:
> Theoretically, you'd use setup_requires to specify packages needed by setup.
> I'm not sure if that works with buildout. I've heard reports that it
> does and reports that
> it doesn't.

I'm pretty sure it doesn't. There is an open bug for it: 
https://bugs.launchpad.net/zc.buildout/+bug/257555 . This bug looks 
related: https://bugs.launchpad.net/zc.buildout/+bug/110133 .

Wichert.



From matthew.brett at gmail.com  Fri Aug 26 19:02:08 2011
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 26 Aug 2011 10:02:08 -0700
Subject: [Distutils] Specify missing install-requires dependencies to
 develop egg?
In-Reply-To: <CAPDm-FgwjyU31eeg4sDFyTdfHrrmMvmM7xCZrB5Y2pJ0GR6W4A@mail.gmail.com>
References: <CAH6Pt5q23owQK728To_34t455A33-Au+hqr-Y558ZjbpA2F2dw@mail.gmail.com>
	<CAPDm-FgwjyU31eeg4sDFyTdfHrrmMvmM7xCZrB5Y2pJ0GR6W4A@mail.gmail.com>
Message-ID: <CAH6Pt5rZ97df4czFPc1Dzi3=WKzx_2dko08b+qRX4x0HdnhR9w@mail.gmail.com>

Hi,

On Fri, Aug 26, 2011 at 6:05 AM, Jim Fulton <jim at zope.com> wrote:
> On Thu, Aug 25, 2011 at 9:06 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> Hi,
>>
>> We have been working on using buildout with a develop package
>> depending on numpy, and ran into trouble because 'numpy' is not
>> specified in the package 'install_requires'.
>>
>> Specifically, we have something like this:
>>
>> [buildout]
>> parts =
>> ? ?nibabel-target
>> ? ?mypy
>>
>> [nibabel-target]
>> recipe = zc.recipe.egg:develop
>> setup = src/nibabel
>>
>> [mypy]
>> recipe = zc.recipe.egg:script
>> eggs =
>> ? ?nibabel
>> interpreter = py
>>
>> 'nibabel' needs to import numpy to install, but does not specify
>> 'numpy' in its setup.py install_requires, because pip install of numpy
>> is fragile, and we wanted to error early in general for an attempted
>> pip install of nibabel, if numpy was not present.
>>
>> But of course the script above raises an error for the
>> 'nibabel-target' part, because of missing numpy:
>>
>> -------------
>> RuntimeError: Cannot import package "numpy" - is it installed?
>> While:
>> ?Installing nibabel-target.
>>
>> An internal error occurred due to a bug in either zc.buildout or in a
>> recipe being used:
>> ------------
>>
>> What we would very much like to do, is to be able to specify the
>> missing install_requires for this package (and for others we are
>> thinking of working with), in the recipe - something like:
>>
>> [nibabel-target]
>> recipe = zc.recipe.egg:develop
>> setup = src/nibabel
>> install-requires =
>> ? ?numpy
>>
>> but we couldn't immediately see a way of specifying such a dependency.
>> ?A quick look at the Develop code in zc/recipe/egg/custom.py
>> suggested that there wasn't an easy way to add some needed egg onto
>> the path at this point.
>>
>> Is there anything we missed that we should have tried?
>>
>> If not, what would be the best way to solve our problem? ?A modified recipe?
>
> Theoretically, you'd use setup_requires to specify packages needed by setup.
> I'm not sure if that works with buildout. I've heard reports that it
> does and reports that
> it doesn't.

Ah - yes - thanks - I had forgotten about setup_requires.

> Why does nibabel want numpy at setup time? If it's to get C incluse files, then
> you may be out of luck, as it's unlikely that buildout will install
> numpy in a way that
> will give nibabel what it wants.

As I was saying in my previous message, nibabel just needs numpy at
runtime.  However, various of our other packages need it at setup
time, to find C include files, or to use numpy.distutils.

When running these various failing buildouts, numpy got installed as
an egg into the ./egg directory.  If I put that egg onto the path with
PYTHONPATH in my bare virtualenv, and then rerun this basic original
buildout.cfg

[buildout]
parts =
    nibabel-target
    mypy

[nibabel-target]
recipe = zc.recipe.egg:develop
setup = src/nibabel

[mypy]
recipe = zc.recipe.egg:script
eggs =
    nibabel
interpreter = py

then it runs to completion.  With ./bin/py:

>>> import numpy
>>> numpy.get_include()
'/home/mb312/tmp/buildbotting/eggs/numpy-1.6.1-py2.6-linux-x86_64.egg/numpy/core/include'

- so I think the C includes would work.

Looking at the bugs pointed to by Wichert, it sounds like your
previous suggestion of a 'setup-requires' for custom and develop
recipes might be the way to go - that was what I was thinking of but
mis-naming in my previous mail.

Cheers,

Matthew

From reinout at vanrees.org  Mon Aug 29 17:58:32 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Mon, 29 Aug 2011 17:58:32 +0200
Subject: [Distutils] mr.developer with older buildout
Message-ID: <j3gcv4$2qt$1@dough.gmane.org>

Hi,

I'm stuck on zc.buildout 1.4.4, but I'd like to use the latest 
mr.developer. I've got the special stick-to-buildout-1.4.4 bootstrap, 
but if I add mr.developer to the "extends=", it grabs zc.buildout 1.5.2...

Ok, I'm pinning it to 1.4.4 and zc.recipe.egg to 1.2.2. Seems OK that way.

But now buildout-versions suddenly starts spitting out a version list 
for versions that I *really* have pinned:

Jinja2 = 2.6
Pygments = 1.4
Sphinx = 1.0.7
mr.developer = 1.18
BeautifulSoup = 3.2.0
Django = 1.3
argparse = 1.2.1

Well, mr.developer is the only unpinned one. But why does the rest 
suddenly pop up? Before mr.developer, buildout-versions was nice and quiet.


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 lgp171188 at gmail.com  Tue Aug 30 11:50:08 2011
From: lgp171188 at gmail.com (L. Guruprasad)
Date: Tue, 30 Aug 2011 15:20:08 +0530
Subject: [Distutils] Installing the dependencies in the develop egg setup.py
Message-ID: <4E5CB250.3010709@gmail.com>

Hi all,

I am having a develop egg in my buildout setup and its setup.py 
specifies a dependency in the install_requires field.

When bin/buildout command is run, the dependencies are not installed. 
But when I mention the dependency in the buildout.cfg file, it does gets 
installed and becomes available to the environment. Alternatively, 
running bin/buildout setup <path to setup.py> file installs the 
dependency correctly and it works. What could be the issue here?

Here is my buildout.cfg
<snip>
[buildout]
extensions = mr.developer
auto-checkout = <project name>
develop = src/wsb
eggs = <project name>
parts = django

[sources]
<project name> = hg <repository URL>

[django]
recipe=djangorecipe
projectegg = <project name>
extra-paths = src/
settings = settings

</snip>

and the setup.py in the project
<snip>
#! /usr/bin/env python

from distutils.core import setup

setup(name='project name',
       version='version number',
       description='description text',
       author='guruprasad',
       author_email='lgp171188 at gmail.com',
       url='project URL',
       install_requires=['recaptcha-client']
       )

</snip>

Thanks in advance.

Thanks & Regards,
Guruprasad

From benji at benjiyork.com  Tue Aug 30 13:36:53 2011
From: benji at benjiyork.com (Benji York)
Date: Tue, 30 Aug 2011 07:36:53 -0400
Subject: [Distutils] Installing the dependencies in the develop egg
	setup.py
In-Reply-To: <4E5CB250.3010709@gmail.com>
References: <4E5CB250.3010709@gmail.com>
Message-ID: <CAC8tyQ4fNz3khMk9SEMWDeFDH2UW2K+6_1B2zFLToZaCbaayvQ@mail.gmail.com>

On Tue, Aug 30, 2011 at 5:50 AM, L. Guruprasad <lgp171188 at gmail.com> wrote:
[...]
> When bin/buildout command is run, the dependencies are not installed.
[...]
> [buildout]
> extensions = mr.developer
> auto-checkout = <project name>
> develop = src/wsb

Is your setup.py in src/wsb?  If not, the "develop" line should point to
the directory that contains it.  The line is often simply "develop = ."
(unless you have more than one develop egg in the project).
-- 
Benji York

From stephane at harobed.org  Tue Aug 30 16:41:48 2011
From: stephane at harobed.org (=?ISO-8859-1?Q?St=E9phane_Klein?=)
Date: Tue, 30 Aug 2011 16:41:48 +0200
Subject: [Distutils] Where can I found the meaning of .pth, .-nspkg.pth,
 .egg-info, .egg-link extensions files of site-package directory ?
Message-ID: <j3isrd$alv$1@dough.gmane.org>

Hi,

where can I found the meaning of all this extensions of "site-packages/" 
folder files :

* .pth ?
* .-nspkg.pth ?
* .egg-info ?
* .egg-link ?

Regards,
Stephane
-- 
St?phane Klein <stephane at harobed.org>
blog: http://stephane-klein.info
Twitter: http://twitter.com/klein_stephane
pro: http://www.is-webdesign.com


From pje at telecommunity.com  Tue Aug 30 19:07:24 2011
From: pje at telecommunity.com (P.J. Eby)
Date: Tue, 30 Aug 2011 13:07:24 -0400
Subject: [Distutils] Where can I found the meaning of .pth, .-nspkg.pth,
 .egg-info, .egg-link extensions files of site-package  directory ?
In-Reply-To: <j3isrd$alv$1@dough.gmane.org>
References: <j3isrd$alv$1@dough.gmane.org>
Message-ID: <20110830170736.628923A405A@sparrow.telecommunity.com>

At 04:41 PM 8/30/2011 +0200, St?phane Klein wrote:
>Hi,
>
>where can I found the meaning of all this extensions of 
>"site-packages/" folder files :
>
>* .pth ?
>* .-nspkg.pth ?
>* .egg-info ?
>* .egg-link ?

All except nspkg.pth can be found at:

   http://peak.telecommunity.com/DevCenter/EggFormats


From lgp171188 at gmail.com  Wed Aug 31 10:52:19 2011
From: lgp171188 at gmail.com (Guruprasad)
Date: Wed, 31 Aug 2011 14:22:19 +0530
Subject: [Distutils] Installing the dependencies in the develop egg
	setup.py
In-Reply-To: <CAC8tyQ4fNz3khMk9SEMWDeFDH2UW2K+6_1B2zFLToZaCbaayvQ@mail.gmail.com>
References: <4E5CB250.3010709@gmail.com>
	<CAC8tyQ4fNz3khMk9SEMWDeFDH2UW2K+6_1B2zFLToZaCbaayvQ@mail.gmail.com>
Message-ID: <CAFZPT6ZT8ZGq5P_KUiLnowMQVS-fEHuxymhqn+WneKs+y=AkTA@mail.gmail.com>

Hi,

On Tue, Aug 30, 2011 at 5:06 PM, Benji York <benji at benjiyork.com> wrote:
> On Tue, Aug 30, 2011 at 5:50 AM, L. Guruprasad <lgp171188 at gmail.com> wrote:
> [...]
>> When bin/buildout command is run, the dependencies are not installed.
> [...]
>> [buildout]
>> extensions = mr.developer
>> auto-checkout = <project name>
>> develop = src/wsb
>
> Is your setup.py in src/wsb? ?If not, the "develop" line should point to
> the directory that contains it. ?The line is often simply "develop = ."
> (unless you have more than one develop egg in the project).

My source code is indeed in src/wsb and there is a setup.py in
src/wsb. But still the dependencies mentioned in that setup.py don't
get installed.

Thanks & Regards,
Guruprasad

From m.van.rees at zestsoftware.nl  Wed Aug 31 14:13:40 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Wed, 31 Aug 2011 14:13:40 +0200
Subject: [Distutils] mr.developer with older buildout
In-Reply-To: <j3gcv4$2qt$1@dough.gmane.org>
References: <j3gcv4$2qt$1@dough.gmane.org>
Message-ID: <j3l8hl$k8l$1@dough.gmane.org>

Op 29-08-11 17:58, Reinout van Rees schreef:
> Hi,
>
> I'm stuck on zc.buildout 1.4.4, but I'd like to use the latest
> mr.developer. I've got the special stick-to-buildout-1.4.4 bootstrap,
> but if I add mr.developer to the "extends=", it grabs zc.buildout 1.5.2...
>
> Ok, I'm pinning it to 1.4.4 and zc.recipe.egg to 1.2.2. Seems OK that way.
>
> But now buildout-versions suddenly starts spitting out a version list
> for versions that I *really* have pinned:
>
> Jinja2 = 2.6
> Pygments = 1.4
> Sphinx = 1.0.7
> mr.developer = 1.18
> BeautifulSoup = 3.2.0
> Django = 1.3
> argparse = 1.2.1
>
> Well, mr.developer is the only unpinned one. But why does the rest
> suddenly pop up? Before mr.developer, buildout-versions was nice and quiet.

When you use both mr.developer and buildout-versions as extensions, the 
order in which you list them matters, as they both hack the versions. 
buildout-versions 1.6 has a fix for that (by me) but that version 
requires zc.buildout 1.5.0 or higher (though that has nothing to do with 
the fix).

The correct order for buildout-versions 1.5 and lower is:

[buildout]
extensions =
     mr.developer
     buildout-versions


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


From m.van.rees at zestsoftware.nl  Wed Aug 31 14:31:50 2011
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Wed, 31 Aug 2011 14:31:50 +0200
Subject: [Distutils] Installing the dependencies in the develop egg
	setup.py
In-Reply-To: <4E5CB250.3010709@gmail.com>
References: <4E5CB250.3010709@gmail.com>
Message-ID: <j3l9jn$rd0$1@dough.gmane.org>

Op 30-08-11 11:50, L. Guruprasad schreef:
> Hi all,
>
> I am having a develop egg in my buildout setup and its setup.py
> specifies a dependency in the install_requires field.
>
> When bin/buildout command is run, the dependencies are not installed.
> But when I mention the dependency in the buildout.cfg file, it does gets
> installed and becomes available to the environment. Alternatively,
> running bin/buildout setup <path to setup.py> file installs the
> dependency correctly and it works. What could be the issue here?
>
> Here is my buildout.cfg
> <snip>
> [buildout]
> extensions = mr.developer
> auto-checkout = <project name>
> develop = src/wsb
> eggs = <project name>
> parts = django
 >
> [sources]
> <project name> = hg <repository URL>
>
> [django]
> recipe=djangorecipe
> projectegg = <project name>
> extra-paths = src/
> settings = settings
>
> </snip>
>
> and the setup.py in the project
> <snip>
> #! /usr/bin/env python
>
> from distutils.core import setup
>
> setup(name='project name',
> version='version number',
> description='description text',
> author='guruprasad',
> author_email='lgp171188 at gmail.com',
> url='project URL',
> install_requires=['recaptcha-client']
> )
>
> </snip>


You should have a line 'sources = sources' in the [buildout] section, 
otherwise the [sources] section is not used (unless that is the default, 
but explicit may be better than implicit here).  When you run buildout 
do you actually get a 'src/<project name>' directory?

It looks to me like src/wsb is not actually used.  You tell buildout 
that it can find a development package in src/wsb if it wants to, but I 
do not see a section that actually wants to use a package with that name.

Or is 'wsb' the same as 'project name'?

Is 'projectegg' the correct spelling in djangorecipe?  I see this in a 
buildout config I have here:

[django]
recipe = djangorecipe
version = 1.2.4
settings = production
eggs =
     ${buildout:eggs}
project = projectname
wsgi = true

This is with djangorecipe 0.20.  A colleague made this buildout so I 
don't know details about this recipe.

Just some thoughts.

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


From reinout at vanrees.org  Wed Aug 31 14:35:19 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Wed, 31 Aug 2011 14:35:19 +0200
Subject: [Distutils] mr.developer with older buildout
In-Reply-To: <j3l8hl$k8l$1@dough.gmane.org>
References: <j3gcv4$2qt$1@dough.gmane.org> <j3l8hl$k8l$1@dough.gmane.org>
Message-ID: <j3l9q7$slv$1@dough.gmane.org>

On 31-08-11 14:13, Maurits van Rees wrote:
> When you use both mr.developer and buildout-versions as extensions, the
> order in which you list them matters, as they both hack the versions.
> buildout-versions 1.6 has a fix for that (by me) but that version
> requires zc.buildout 1.5.0 or higher (though that has nothing to do with
> the fix).
>
> The correct order for buildout-versions 1.5 and lower is:
>
> [buildout]
> extensions =
>      mr.developer
>      buildout-versions

Works like a charm, thanks!


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 cedric.dsm at tiolive.com  Wed Aug 31 18:30:15 2011
From: cedric.dsm at tiolive.com (=?iso-8859-1?Q?C=E9dric_de_Saint_Martin?=)
Date: Wed, 31 Aug 2011 18:30:15 +0200
Subject: [Distutils] SlapOS : a Cloud OS built on top of Buildout
Message-ID: <FA280310-38A9-4731-9FF9-D6783DD96CFD@tiolive.com>

Hello,

We are the SlapOS team, from Nexedi (editor of ERP5, a Zope-based ERP/CRM), and we feel that it is time for us to show you what we have built with Buildout so far.

We've been working for more than a year with Buildout to create a Distributed Cloud Computing OS.
But before that, I would like to thank you for making Buildout, which has really helped us a lot. We are very happy users of buildout and we try to promote it outside Nexedi.

Let me quickly explain you the project. 

One of the idea behind SlapOS came from the fact that we had to deploy ERP5 on environments we did not control. We started to use buildout heavily to provide a complete ERP5 stack from the ground up, only relying on the glibc to have stable instances and compiling every dependency to handle differences between distributions. We thought we could generalize the idea to a point we can deploy any kind of software, on any UNIX OS.

One other idea behind SlapOS is that we think that classical, centralized cloud is not resilient enough to provide the kind of high availability which most cloud vendors promise but do not achieve in reality. We have two solutions for this problem : putting all intelligence to end point and letting the (buildout) recipe choose for re-instantiation in another datacenter/computer if current service is too bad, or is dead, and putting most of the servers out of the datacenter : at home, in offices, and everywhere you can put them in. Thus creating a *really* distributed cloud computing system.

Of course, everything we did is Free Software.

We made Buildout the central part of SlapOS, using it to deploy software and instances. Let me explain.
First, we install a software on a computer using Buildout profile like this one : 
http://gitorious.org/slapos/slapos/blobs/master/software/mysql-5.1/software.cfg
Here, the whole software and all its dependencies get installed. At this point, software is not usable, because there is no configuration file, i.e MySQL and dependencies is installed but no database, configuration, user or anything exist.

Then, we can request deployment of many instances of this installed software using this kind of Buildout profile :
http://gitorious.org/slapos/slapos/blobs/master/software/mysql-5.1/instance.cfg
And this kind of recipe : 
http://gitorious.org/slapos/slapos/blobs/master/slapos/recipe/mysql/__init__.py

It will reuse installed software by creating wrappers, configuration files and anything specific to an instance. In the case of MySQL, it will create a database with possibly data in it, user, and configuration file. You can then deploy several independent instances based on the same software.


We made a couple of improvements in Buildout, at least for us. We will write soon in other topics in this mailing list to see if it can be integrated in Buildout repository. If you think we can help in a better way or contribute to buildout in a better way, please let us know. We will be happy to help.

We also wrote a page to explain our views on buildout for SlapOS : http://www.slapos.org/wiki/slapos.Why.Buildout. Here we explain in detail why we choose Buildout in the first place, and we try to show that some critics of buildout are not well formed.

If you are interested in the internals of the project, we can provide you more SlapOS materials. We are in the phase where a lot of documentation is getting written, and SlapOS is becoming usable in production sites.

Best regards,
The SlapOS Team

-----------------
C?dric de Saint Martin,
SlapOS Community Manager @ Nexedi

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