From justizin at vongogo.net  Sun Nov  2 23:04:50 2008
From: justizin at vongogo.net (Justin Ryan)
Date: Sun, 2 Nov 2008 14:04:50 -0800
Subject: [Distutils] zc.buildout, recipe downloading dev eggs
In-Reply-To: <da81e4160810292134x4e28aae4t9ac6bda371f28499@mail.gmail.com>
References: <da81e4160810242208g11d3303bt4462c5e78f873a0f@mail.gmail.com>
	<D9063043-2C27-4BB1-8358-4DC5FCC6506A@zope.com>
	<da81e4160810251055j24b31051m8526e9a143a6a646@mail.gmail.com>
	<F9CD94A7-EAE2-4612-94AF-B9561242998A@zope.com>
	<da81e4160810251205l4adbaf08p95adbe16f1612b7b@mail.gmail.com>
	<da81e4160810261204q8b3ed3aw6abe99f9727cd476@mail.gmail.com>
	<da81e4160810292134x4e28aae4t9ac6bda371f28499@mail.gmail.com>
Message-ID: <da81e4160811021404v5d907c70hdeb3471a511bda8d@mail.gmail.com>

Jim?  Anyone?  I agree the behaviour we discussed makes sense, but I'm
unclear why it doesn't work as discussed, it isn't documented, and I
haven't found a clear indicator in the source that it should work,
though I clearly could learn a bit more about buildout recipes.

On Wed, Oct 29, 2008 at 8:34 PM, Justin Ryan <justizin at vongogo.net> wrote:
> On closer inspection, the zc.recipe.egg documentation doesn't make any
> mention of this feature, though I think it's a great idea and hats off
> to the author if it was originally intended to work that way but
> doesn't, or maybe broke at some point because a contributor didn't
> understand the feature.
>
> If there's some work to be done, I'm happy to help.
>
> I really want this style of buildout usage to be possible.
>
> Let's work together!  Our Foundation's goals line up with Zope extremeley well!
>
> :)
>
> Peace,
>
> J
>
> On Sun, Oct 26, 2008 at 12:04 PM, Justin Ryan <justizin at vongogo.net> wrote:
>>> On Sat, Oct 25, 2008 at 11:05 AM, Jim Fulton <jim at zope.com> wrote:
>>
>>
>>>>
>>>> No.  buildout doesn't care when develop eggs are created. If you use the buildout develop option to create develop eggs, then they are created early.  If you use the zc.recipe.egg:develop recipe, or some other recipe that creates develop eggs, then you can create them later.
>>>
>>> Ah, fantastic, I came to an understanding of this last week or so, but some example usage I found led me to believe it wouldn't work.
>>>
>>> Perfect!  Thanks.
>>>
>>
>>
>> OK, I gave this a shot in a simple case, a buildout you can find here:
>>
>>  http://dev.vongogo.net/bzr/repos/buildouts/getpaid.buildout/
>>
>> The develop option in getpaid.cfg seems to be ignored entirely, I
>> don't see any messages like "We have a develop egg", and it fails to
>> find a distribution for yoma.batching, which is in the develop list,
>> though it finds others which are available in PyPI.
>>
>> If I'm working on another false assumption, or parsed something from
>> you or the documentation wrong, please correct.  I just want to be
>> able to deploy in this style. :)
>>
>> Best,
>>
>> J
>>
>> --
>> Robert Half - "When one teaches, two learn."
>>
>
>
>
> --
> Robert Half - "When one teaches, two learn."
>



-- 
Robert Half - "When one teaches, two learn."

From ross at kallisti.us  Fri Nov  7 17:04:50 2008
From: ross at kallisti.us (Ross Vandegrift)
Date: Fri, 7 Nov 2008 11:04:50 -0500
Subject: [Distutils] Expressing a dependancy on ElementTree
Message-ID: <20081107160450.GC31300@kallisti.us>

Hello everyone,

I have a library that depends on ElementTree and needs to support both
Python2.4 and Python2.5 style inclusion of the library.

In Python2.4, it's a standalone package and can be fetched by
"elementtree>=1.2".
In Python2.5, it's integrated into the standard library as xml.etree.

If I pass "elementtree>=1.2.6" in install_requires, setuptools
downloads the Python2.4 standalone version of the package under
Python2.5.

Any way I can express a dependency on elementtree if and only if I'm
installing into 2.4?

-- 
Ross Vandegrift
ross at kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

From ziade.tarek at gmail.com  Fri Nov  7 18:25:35 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 7 Nov 2008 18:25:35 +0100
Subject: [Distutils] Pycon: Sprint and Panel
Message-ID: <94bdd2610811070925y4d2c240evbf7e1f8b72e472b2@mail.gmail.com>

Hello

I would like to know if people would be interested in some events during Pycon:

- a Sprint for packaging+PyPI matters (already submited)
- a "packaging" panel during Pycon    "release/distribute a Python
application today, solutions and problems"

For the latter, let me know here or in private if you would like to
contribute to that panel
a good panel would probably require os packagers and people from these
two MLs to be involved. If I have enough people interested
I will submit this panel as a proposal for Pycon.

Cheers
Tarek

-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/

From pje at telecommunity.com  Fri Nov  7 18:29:30 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 07 Nov 2008 12:29:30 -0500
Subject: [Distutils] Expressing a dependancy on ElementTree
In-Reply-To: <20081107160450.GC31300@kallisti.us>
References: <20081107160450.GC31300@kallisti.us>
Message-ID: <20081107172807.75B963A4092@sparrow.telecommunity.com>

At 11:04 AM 11/7/2008 -0500, Ross Vandegrift wrote:
>Hello everyone,
>
>I have a library that depends on ElementTree and needs to support both
>Python2.4 and Python2.5 style inclusion of the library.
>
>In Python2.4, it's a standalone package and can be fetched by
>"elementtree>=1.2".
>In Python2.5, it's integrated into the standard library as xml.etree.
>
>If I pass "elementtree>=1.2.6" in install_requires, setuptools
>downloads the Python2.4 standalone version of the package under
>Python2.5.
>
>Any way I can express a dependency on elementtree if and only if I'm
>installing into 2.4?

Have your setup.py check what version it's running under, and declare 
the right dependency (or lack thereof).  This is really the only way 
to deal with things that are bundled in the stdlib, at least until 
such time as the stdlib includes .egg-info for bundled packages.


From ross at kallisti.us  Fri Nov  7 23:38:19 2008
From: ross at kallisti.us (Ross Vandegrift)
Date: Fri, 7 Nov 2008 17:38:19 -0500
Subject: [Distutils] Expressing a dependancy on ElementTree
In-Reply-To: <20081107172807.75B963A4092@sparrow.telecommunity.com>
References: <20081107160450.GC31300@kallisti.us>
	<20081107172807.75B963A4092@sparrow.telecommunity.com>
Message-ID: <20081107223819.GF31300@kallisti.us>

On Fri, Nov 07, 2008 at 12:29:30PM -0500, Phillip J. Eby wrote:
> Have your setup.py check what version it's running under, and declare 
> the right dependency (or lack thereof).  This is really the only way 
> to deal with things that are bundled in the stdlib, at least until 
> such time as the stdlib includes .egg-info for bundled packages.

Okay - I didn't think of that.  Not such a terrible solution :)

-- 
Ross Vandegrift
ross at kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie

From abhigyan_agrawal at in.ibm.com  Tue Nov 11 11:00:53 2008
From: abhigyan_agrawal at in.ibm.com (Abhigyan Agrawal1)
Date: Tue, 11 Nov 2008 15:30:53 +0530
Subject: [Distutils] setuptools Windows installer for Python 2.6
Message-ID: <OFCE97B2C1.DD3FDB34-ON652574FE.0036B825-652574FE.0036E9B4@in.ibm.com>

Hi,
        I am wondering if there is any plan to release a windows installer 
for setuptools setup for Python 2.6? 

Thanks,
Abhigyan 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081111/9527f3b6/attachment.htm>

From ntv1534 at gmail.com  Wed Nov 12 11:38:45 2008
From: ntv1534 at gmail.com (Nick Vaidyanathan)
Date: Wed, 12 Nov 2008 03:38:45 -0700
Subject: [Distutils] Vista x64 + Python 2.6 = easy_install setup issues
Message-ID: <66dbc6a60811120238u603e8471haf1003d378c436c7@mail.gmail.com>

I've successfully replicated this on both my laptop and my desktop. User
Account control is turned off on both machines. Python exists in non C:\
partitions on both. I download the easy_install package, run setup python
install in the directory, and get the following:

Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

<root>\setuptools-0.6c9>python setup.py install
running install
running bdist_egg
running egg_info
writing setuptools.egg-info\PKG-INFO
writing top-level names to setuptools.egg-info\top_level.txt
writing dependency_links to setuptools.egg-info\dependency_links.txt
writing entry points to setuptools.egg-info\entry_points.txt
reading manifest file 'setuptools.egg-info\SOURCES.txt'
writing manifest file 'setuptools.egg-info\SOURCES.txt'
installing library code to build\bdist.win-amd64\egg
running install_lib
running build_py
creating build
creating build\lib
copying pkg_resources.py -> build\lib
copying easy_install.py -> build\lib
copying site.py -> build\lib
creating build\lib\setuptools
copying setuptools\archive_util.py -> build\lib\setuptools
copying setuptools\depends.py -> build\lib\setuptools
copying setuptools\dist.py -> build\lib\setuptools
copying setuptools\extension.py -> build\lib\setuptools
copying setuptools\package_index.py -> build\lib\setuptools
copying setuptools\sandbox.py -> build\lib\setuptools
copying setuptools\__init__.py -> build\lib\setuptools
creating build\lib\setuptools\command
copying setuptools\command\alias.py -> build\lib\setuptools\command
copying setuptools\command\bdist_egg.py -> build\lib\setuptools\command
copying setuptools\command\bdist_rpm.py -> build\lib\setuptools\command
copying setuptools\command\bdist_wininst.py -> build\lib\setuptools\command
copying setuptools\command\build_ext.py -> build\lib\setuptools\command
copying setuptools\command\build_py.py -> build\lib\setuptools\command
copying setuptools\command\develop.py -> build\lib\setuptools\command
copying setuptools\command\easy_install.py -> build\lib\setuptools\command
copying setuptools\command\egg_info.py -> build\lib\setuptools\command
copying setuptools\command\install.py -> build\lib\setuptools\command
copying setuptools\command\install_egg_info.py ->
build\lib\setuptools\command
copying setuptools\command\install_lib.py -> build\lib\setuptools\command
copying setuptools\command\install_scripts.py ->
build\lib\setuptools\command
copying setuptools\command\register.py -> build\lib\setuptools\command
copying setuptools\command\rotate.py -> build\lib\setuptools\command
copying setuptools\command\saveopts.py -> build\lib\setuptools\command
copying setuptools\command\sdist.py -> build\lib\setuptools\command
copying setuptools\command\setopt.py -> build\lib\setuptools\command
copying setuptools\command\test.py -> build\lib\setuptools\command
copying setuptools\command\upload.py -> build\lib\setuptools\command
copying setuptools\command\__init__.py -> build\lib\setuptools\command
creating build\lib\setuptools\tests
copying setuptools\tests\doctest.py -> build\lib\setuptools\tests
copying setuptools\tests\test_packageindex.py -> build\lib\setuptools\tests
copying setuptools\tests\test_resources.py -> build\lib\setuptools\tests
copying setuptools\tests\__init__.py -> build\lib\setuptools\tests
copying setuptools\cli.exe -> build\lib\setuptools
copying setuptools\gui.exe -> build\lib\setuptools
creating build\bdist.win-amd64
creating build\bdist.win-amd64\egg
copying build\lib\easy_install.py -> build\bdist.win-amd64\egg
copying build\lib\pkg_resources.py -> build\bdist.win-amd64\egg
creating build\bdist.win-amd64\egg\setuptools
copying build\lib\setuptools\archive_util.py ->
build\bdist.win-amd64\egg\setupt
ools
copying build\lib\setuptools\cli.exe -> build\bdist.win-amd64\egg\setuptools
creating build\bdist.win-amd64\egg\setuptools\command
copying build\lib\setuptools\command\alias.py ->
build\bdist.win-amd64\egg\setup
tools\command
copying build\lib\setuptools\command\bdist_egg.py ->
build\bdist.win-amd64\egg\s
etuptools\command
copying build\lib\setuptools\command\bdist_rpm.py ->
build\bdist.win-amd64\egg\s
etuptools\command
copying build\lib\setuptools\command\bdist_wininst.py ->
build\bdist.win-amd64\e
gg\setuptools\command
copying build\lib\setuptools\command\build_ext.py ->
build\bdist.win-amd64\egg\s
etuptools\command
copying build\lib\setuptools\command\build_py.py ->
build\bdist.win-amd64\egg\se
tuptools\command
copying build\lib\setuptools\command\develop.py ->
build\bdist.win-amd64\egg\set
uptools\command
copying build\lib\setuptools\command\easy_install.py ->
build\bdist.win-amd64\eg
g\setuptools\command
copying build\lib\setuptools\command\egg_info.py ->
build\bdist.win-amd64\egg\se
tuptools\command
copying build\lib\setuptools\command\install.py ->
build\bdist.win-amd64\egg\set
uptools\command
copying build\lib\setuptools\command\install_egg_info.py ->
build\bdist.win-amd6
4\egg\setuptools\command
copying build\lib\setuptools\command\install_lib.py ->
build\bdist.win-amd64\egg
\setuptools\command
copying build\lib\setuptools\command\install_scripts.py ->
build\bdist.win-amd64
\egg\setuptools\command
copying build\lib\setuptools\command\register.py ->
build\bdist.win-amd64\egg\se
tuptools\command
copying build\lib\setuptools\command\rotate.py ->
build\bdist.win-amd64\egg\setu
ptools\command
copying build\lib\setuptools\command\saveopts.py ->
build\bdist.win-amd64\egg\se
tuptools\command
copying build\lib\setuptools\command\sdist.py ->
build\bdist.win-amd64\egg\setup
tools\command
copying build\lib\setuptools\command\setopt.py ->
build\bdist.win-amd64\egg\setu
ptools\command
copying build\lib\setuptools\command\test.py ->
build\bdist.win-amd64\egg\setupt
ools\command
copying build\lib\setuptools\command\upload.py ->
build\bdist.win-amd64\egg\setu
ptools\command
copying build\lib\setuptools\command\__init__.py ->
build\bdist.win-amd64\egg\se
tuptools\command
copying build\lib\setuptools\depends.py ->
build\bdist.win-amd64\egg\setuptools
copying build\lib\setuptools\dist.py -> build\bdist.win-amd64\egg\setuptools
copying build\lib\setuptools\extension.py ->
build\bdist.win-amd64\egg\setuptool
s
copying build\lib\setuptools\gui.exe -> build\bdist.win-amd64\egg\setuptools
copying build\lib\setuptools\package_index.py ->
build\bdist.win-amd64\egg\setup
tools
copying build\lib\setuptools\sandbox.py ->
build\bdist.win-amd64\egg\setuptools
creating build\bdist.win-amd64\egg\setuptools\tests
copying build\lib\setuptools\tests\doctest.py ->
build\bdist.win-amd64\egg\setup
tools\tests
copying build\lib\setuptools\tests\test_packageindex.py ->
build\bdist.win-amd64
\egg\setuptools\tests
copying build\lib\setuptools\tests\test_resources.py ->
build\bdist.win-amd64\eg
g\setuptools\tests
copying build\lib\setuptools\tests\__init__.py ->
build\bdist.win-amd64\egg\setu
ptools\tests
copying build\lib\setuptools\__init__.py ->
build\bdist.win-amd64\egg\setuptools

copying build\lib\site.py -> build\bdist.win-amd64\egg
byte-compiling build\bdist.win-amd64\egg\easy_install.py to easy_install.pyc
byte-compiling build\bdist.win-amd64\egg\pkg_resources.py to
pkg_resources.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\archive_util.py to
archive_u
til.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\alias.py to
alias.py
c
byte-compiling build\bdist.win-amd64\egg\setuptools\command\bdist_egg.py to
bdis
t_egg.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\bdist_rpm.py to
bdis
t_rpm.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\bdist_wininst.py
to
bdist_wininst.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\build_ext.py to
buil
d_ext.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\build_py.py to
build
_py.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\develop.py to
develo
p.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\easy_install.py
to e
asy_install.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\egg_info.py to
egg_i
nfo.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\install.py to
instal
l.pyc
byte-compiling
build\bdist.win-amd64\egg\setuptools\command\install_egg_info.py
to install_egg_info.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\install_lib.py
to in
stall_lib.pyc
byte-compiling
build\bdist.win-amd64\egg\setuptools\command\install_scripts.py t
o install_scripts.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\register.py to
regis
ter.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\rotate.py to
rotate.
pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\saveopts.py to
saveo
pts.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\sdist.py to
sdist.py
c
byte-compiling build\bdist.win-amd64\egg\setuptools\command\setopt.py to
setopt.
pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\test.py to
test.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\upload.py to
upload.
pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\command\__init__.py to
__ini
t__.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\depends.py to
depends.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\dist.py to dist.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\extension.py to
extension.py
c
byte-compiling build\bdist.win-amd64\egg\setuptools\package_index.py to
package_
index.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\sandbox.py to
sandbox.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\tests\doctest.py to
doctest.
pyc
byte-compiling
build\bdist.win-amd64\egg\setuptools\tests\test_packageindex.py t
o test_packageindex.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\tests\test_resources.py
to t
est_resources.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\tests\__init__.py to
__init_
_.pyc
byte-compiling build\bdist.win-amd64\egg\setuptools\__init__.py to
__init__.pyc
byte-compiling build\bdist.win-amd64\egg\site.py to site.pyc
creating build\bdist.win-amd64\egg\EGG-INFO
copying setuptools.egg-info\PKG-INFO -> build\bdist.win-amd64\egg\EGG-INFO
copying setuptools.egg-info\SOURCES.txt ->
build\bdist.win-amd64\egg\EGG-INFO
copying setuptools.egg-info\dependency_links.txt ->
build\bdist.win-amd64\egg\EG
G-INFO
copying setuptools.egg-info\entry_points.txt ->
build\bdist.win-amd64\egg\EGG-IN
FO
copying setuptools.egg-info\top_level.txt ->
build\bdist.win-amd64\egg\EGG-INFO
copying setuptools.egg-info\zip-safe -> build\bdist.win-amd64\egg\EGG-INFO
creating dist
creating 'dist\setuptools-0.6c9-py2.6.egg' and adding
'build\bdist.win-amd64\egg
' to it
removing 'build\bdist.win-amd64\egg' (and everything under it)
Processing setuptools-0.6c9-py2.6.egg
Removing g:\python26\lib\site-packages\setuptools-0.6c9-py2.6.egg
Copying setuptools-0.6c9-py2.6.egg to g:\python26\lib\site-packages
setuptools 0.6c9 is already the active version in easy-install.pth
Installing easy_install-script.py script to G:\Python26\Scripts
Installing easy_install.exe script to G:\Python26\Scripts
Installing easy_install-2.6-script.py script to G:\Python26\Scripts
Installing easy_install-2.6.exe script to G:\Python26\Scripts

Installed g:\python26\lib\site-packages\setuptools-0.6c9-py2.6.egg
Processing dependencies for setuptools==0.6c9
Finished processing dependencies for setuptools==0.6c9

<root>\setuptools-0.6c9>easy_install numpy
*Cannot find Python executable G:\Python26\python.exe*

<root>\setuptools-0.6c9>cd G:\Python26\Scripts

G:\Python26\Scripts>easy_install-2.6.exe
Cannot find Python executable G:\Python26\python.exe

G:\Python26\Scripts>

The easy_install app does not work. I can use the easy_install-2.6-script.py,
however. The weird thing is that the error message makes absolutely no sense
to me. As part of the install process I obviously had to run python, and the
installer put files (correctly) into the site-packages directory and all of
the other dirs. Ideas?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081112/05937cd9/attachment.htm>

From asmodai at in-nomine.org  Wed Nov 12 11:44:31 2008
From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven)
Date: Wed, 12 Nov 2008 11:44:31 +0100
Subject: [Distutils] Vista x64 + Python 2.6 = easy_install setup issues
In-Reply-To: <66dbc6a60811120238u603e8471haf1003d378c436c7@mail.gmail.com>
References: <66dbc6a60811120238u603e8471haf1003d378c436c7@mail.gmail.com>
Message-ID: <20081112104431.GC10621@nexus.in-nomine.org>

-On [20081112 11:39], Nick Vaidyanathan (ntv1534 at gmail.com) wrote:
><root>\setuptools-0.6c9>python setup.py install

[snip]

>creating build\bdist.win-amd64

[snip]

>G:\Python26\Scripts>easy_install-2.6.exe
>Cannot find Python executable G:\Python26\python.exe

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

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
????? ?????? ??? ?? ??????
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
The path up and down is one and the same...

From pbeadling at mail2web.com  Fri Nov 14 01:53:27 2008
From: pbeadling at mail2web.com (Phil)
Date: Fri, 14 Nov 2008 01:53:27 +0100
Subject: [Distutils] Including third party libs with buildout
Message-ID: <C5428A97.1EF7%pbeadling@mail2web.com>

Hi,

I?m having a bash at writing a buildout script for an app I?m working on.
My app uses some third part stuff like pygtk and vlc?s python bindings which
buildout does a great job of setting up in my dev environment.  The problem
I have is when I want to produce a final distribution  - for example, in the
config below do I make sure that the libs created by the [pygtk] and
[vlc_bindings] sections are packaged in my final deployment (using bdist the
.so files should just be in the libs/ directory and using sdist, I guess the
source should be bundled)?  Nothing I have tried seems to work (adding them
to the eggs section of [mySop] or including them in setup.py as
requirements).  I?m sure there must be an easy way to do this ? but it has
me stumped!

Any help greatly appreciated,

Phil.

setup.py


from setuptools import setup, find_packages
setup( name='mySop',
       version='0.1',
       packages=find_packages('.'),
       include_package_data=True,
       package_data={ 'SopGui':['data/mySop.glade.xml'] },
       entry_points={ 'console_scripts' : ['mySop = MySop.main:entry_point']
},
       ) 


**********************
buildout.cfg


[buildout]
parts = sp-sc pygtk vlc_bindings glade_xml mySop
develop = .

[sp-sc]
recipe = hexagoniat.recipe.download
url = http://download.sopcast.cn/download/sp-auth.tgz
strip-top-level-dir = true
ignore-existing = true
destination = ${buildout:directory}/bin

[pygtk]
recipe = tl.buildout_gtk
pycairo-url = http://www.cairographics.org/releases/pycairo-1.4.12.tar.gz
pygobject-url = 
http://ftp.gnome.org/pub/GNOME/sources/pygobject/2.15/pygobject-2.15.4.tar.g
z
pygobject-md5sum = 0529aed070916e744a60ccddd5c0aaf8
pygtk-url = 
http://ftp.gnome.org/pub/GNOME/sources/pygtk/2.13/pygtk-2.13.0.tar.gz
pygtk-md5sum = d5094d254288556256ee5f93b0c5ae9b

[vlc_bindings]
recipe = zerokspot.recipe.distutils
urls = 
http://git.videolan.org/?p=vlc.git;a=snapshot;h=78915c05e904cbaba9360a3c8fa0
f945a785cbb6;sf=tgz

[glade_xml]
recipe = iw.recipe.cmd
on_install=true
on_update=true
cmds = gtk-builder-convert MySop/data/mySop.glade MySop/data/mySop.glade.xml

[mySop]
recipe = zc.recipe.egg
extra-paths = ${vlc_bindings:extra-path}
              ${pygtk:path}
scripts = mySop





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081114/2b96b042/attachment.htm>

From benji at zope.com  Fri Nov 14 14:14:17 2008
From: benji at zope.com (Benji York)
Date: Fri, 14 Nov 2008 08:14:17 -0500
Subject: [Distutils] Including third party libs with buildout
In-Reply-To: <C5428A97.1EF7%pbeadling@mail2web.com>
References: <AclF+8kdMghHClqyRXmEsYRJ359KGQ==>
	<C5428A97.1EF7%pbeadling@mail2web.com>
Message-ID: <e5fff6640811140514p39512806k53c1e74a601d1416@mail.gmail.com>

2008/11/13 Phil <pbeadling at mail2web.com>:
> Hi,
>
> I'm having a bash at writing a buildout script for an app I'm working on.
>  My app uses some third part stuff like pygtk and vlc's python bindings
> which buildout does a great job of setting up in my dev environment.  The
> problem I have is when I want to produce a final distribution  - for
> example, in the config below do I make sure that the libs created by the
> [pygtk] and [vlc_bindings] sections are packaged in my final deployment
> (using bdist the .so files should just be in the libs/ directory and using
> sdist, I guess the source should be bundled)?

One option is to use zc.sourcerelease
(http://pypi.python.org/pypi/zc.sourcerelease) to generate a source
release and use that as the basis for binary releases.
-- 
Benji York
Senior Software Engineer
Zope Corporation

From chris at simplistix.co.uk  Sat Nov 15 14:28:26 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Nov 2008 13:28:26 +0000
Subject: [Distutils] [buildout] private eggs and egg repositories
Message-ID: <491ECE7A.1020808@simplistix.co.uk>

Hi All,

I'm getting a growing number of customer-specific and non-open-source 
eggs. I used to just put these in as svn:externals and then add the path 
in as a develop egg, however, I'm not sure this is going to scale.

What I'd like to do is have a "local egg repository" that I can put 
these eggs in and then just point buildout at it.

Has anyone done this before?

Failing that, is there any way in buildout to say "use this egg 
repository in favour of pypi, and only look at pypi if the egg isn't 
found in the local repository"?

Also, does anyone have any software that makes a good egg repository?

Does anyone have anything that supports the equivalent of:

python setup.py upload

...but to a local repository?

cheers,

Chris

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

From lists at zopyx.com  Sat Nov 15 14:31:14 2008
From: lists at zopyx.com (Andreas Jung)
Date: Sat, 15 Nov 2008 14:31:14 +0100
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <491ECE7A.1020808@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk>
Message-ID: <491ECF22.1060402@zopyx.com>

On 15.11.2008 14:28 Uhr, Chris Withers wrote:
> Hi All,
>
> I'm getting a growing number of customer-specific and non-open-source
> eggs. I used to just put these in as svn:externals and then add the path
> in as a develop egg, however, I'm not sure this is going to scale.
>
> What I'd like to do is have a "local egg repository" that I can put
> these eggs in and then just point buildout at it.

http://pypi.python.org/pypi/haufe.eggserver

-aj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081115/68d67b90/attachment.vcf>

From jim at zope.com  Sat Nov 15 15:20:14 2008
From: jim at zope.com (Jim Fulton)
Date: Sat, 15 Nov 2008 09:20:14 -0500
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <491ECE7A.1020808@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk>
Message-ID: <B575ECAD-2B8B-49C8-ABE3-E62EC7C59BA2@zope.com>


On Nov 15, 2008, at 8:28 AM, Chris Withers wrote:

> Hi All,
>
> I'm getting a growing number of customer-specific and non-open- 
> source eggs. I used to just put these in as svn:externals and then  
> add the path in as a develop egg, however, I'm not sure this is  
> going to scale.
>
> What I'd like to do is have a "local egg repository" that I can put  
> these eggs in and then just point buildout at it.
>
> Has anyone done this before?

Yes

> Failing that, is there any way in buildout to say "use this egg  
> repository in favour of pypi, and only look at pypi if the egg isn't  
> found in the local repository"?

Just set up a flat directory somewhere and tell buildout (or any other  
setuptools-based software, like easy_install) to add it to its list of  
find links.

A repository doesn't have to be a formal index.

We simply set up an sftp server and point buildout at it using the  
buildoutsftp buildout extension and sftp urls, as in:

   extensions = zc.buildoutsftp
   find-links = sftp://private.zope.com/private

This provides restricted access with authentication using ssh keys.

Jim

--
Jim Fulton
Zope Corporation



From chris at simplistix.co.uk  Sat Nov 15 15:22:45 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Nov 2008 14:22:45 +0000
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <B575ECAD-2B8B-49C8-ABE3-E62EC7C59BA2@zope.com>
References: <491ECE7A.1020808@simplistix.co.uk>
	<B575ECAD-2B8B-49C8-ABE3-E62EC7C59BA2@zope.com>
Message-ID: <491EDB35.3070002@simplistix.co.uk>

Jim Fulton wrote:
> 
>> Has anyone done this before?
> 
> Yes

I had a feeling that might be the case ;-)

>> Failing that, is there any way in buildout to say "use this egg 
>> repository in favour of pypi, and only look at pypi if the egg isn't 
>> found in the local repository"?
> 
> Just set up a flat directory somewhere and tell buildout (or any other 
> setuptools-based software, like easy_install) to add it to its list of 
> find links.

Does find-links take preference over the repository? I thought *all* 
find-links *and* the repository were checked and the best match used?

> We simply set up an sftp server and point buildout at it using the 
> buildoutsftp buildout extension and sftp urls, as in:
> 
>   extensions = zc.buildoutsftp
>   find-links = sftp://private.zope.com/private
> 
> This provides restricted access with authentication using ssh keys.

Cool. Out of interest, what ftp server do you use for this and how do 
you build/upload the eggs to sftp://private.zope.com/private?

cheers,

Chris

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

From jim at zope.com  Sat Nov 15 15:26:36 2008
From: jim at zope.com (Jim Fulton)
Date: Sat, 15 Nov 2008 09:26:36 -0500
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <491EDB35.3070002@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk>
	<B575ECAD-2B8B-49C8-ABE3-E62EC7C59BA2@zope.com>
	<491EDB35.3070002@simplistix.co.uk>
Message-ID: <B013BDF4-778B-4A61-BA13-8765AC25540A@zope.com>


On Nov 15, 2008, at 9:22 AM, Chris Withers wrote:
...
> Does find-links take preference over the repository? I thought *all*  
> find-links *and* the repository were checked and the best match used?

find-links are searched before the index

>> We simply set up an sftp server and point buildout at it using the  
>> buildoutsftp buildout extension and sftp urls, as in:
>>  extensions = zc.buildoutsftp
>>  find-links = sftp://private.zope.com/private
>> This provides restricted access with authentication using ssh keys.
>
> Cool. Out of interest, what ftp server do you use for this

The one built in to open ssh.

> and how do you build/upload the eggs to sftp://private.zope.com/private?


We build using the setup sdist command and the scp the result to the  
server.

Jim

--
Jim Fulton
Zope Corporation



From chris at simplistix.co.uk  Sat Nov 15 15:26:31 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Nov 2008 14:26:31 +0000
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <491ECF22.1060402@zopyx.com>
References: <491ECE7A.1020808@simplistix.co.uk> <491ECF22.1060402@zopyx.com>
Message-ID: <491EDC17.2000203@simplistix.co.uk>

Andreas Jung wrote:
>> What I'd like to do is have a "local egg repository" that I can put
>> these eggs in and then just point buildout at it.
> 
> http://pypi.python.org/pypi/haufe.eggserver

So you basically add the egg-server url as a find-links option?

If you have a find-links in ~/.buildout/default.cfg, will that override 
or be combined with one in a buildout.cfg?

cheers,

Chris

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

From chris at simplistix.co.uk  Sat Nov 15 15:32:48 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Sat, 15 Nov 2008 14:32:48 +0000
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <B013BDF4-778B-4A61-BA13-8765AC25540A@zope.com>
References: <491ECE7A.1020808@simplistix.co.uk>
	<B575ECAD-2B8B-49C8-ABE3-E62EC7C59BA2@zope.com>
	<491EDB35.3070002@simplistix.co.uk>
	<B013BDF4-778B-4A61-BA13-8765AC25540A@zope.com>
Message-ID: <491EDD90.10709@simplistix.co.uk>

Jim Fulton wrote:
> 
>> Does find-links take preference over the repository? I thought *all* 
>> find-links *and* the repository were checked and the best match used?
> 
> find-links are searched before the index

Are all find-links searched, regardless of whether they're in 
~/.buildout/default.cfg or a buildout.cfg?
(ie: what happens if both have find-links in them?)

>>> We simply set up an sftp server and point buildout at it using the 
>>> buildoutsftp buildout extension and sftp urls, as in:
>>>  extensions = zc.buildoutsftp
>>>  find-links = sftp://private.zope.com/private
>>> This provides restricted access with authentication using ssh keys.
>>
>> Cool. Out of interest, what ftp server do you use for this
> 
> The one built in to open ssh.

So I assume the clients just have to be able to have their public key on 
the sftp server? Do you use specific keys for sftp or do the clients 
just have shell access on the server?

>> and how do you build/upload the eggs to sftp://private.zope.com/private?
> 
> We build using the setup sdist command and the scp the result to the 
> server.

*nods*

cheers,

Chris

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

From jim at zope.com  Sat Nov 15 15:43:55 2008
From: jim at zope.com (Jim Fulton)
Date: Sat, 15 Nov 2008 09:43:55 -0500
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <491EDD90.10709@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk>
	<B575ECAD-2B8B-49C8-ABE3-E62EC7C59BA2@zope.com>
	<491EDB35.3070002@simplistix.co.uk>
	<B013BDF4-778B-4A61-BA13-8765AC25540A@zope.com>
	<491EDD90.10709@simplistix.co.uk>
Message-ID: <259B3221-A00D-4808-8281-D3E6D484AAEF@zope.com>


On Nov 15, 2008, at 9:32 AM, Chris Withers wrote:

> Jim Fulton wrote:
>>> Does find-links take preference over the repository? I thought  
>>> *all* find-links *and* the repository were checked and the best  
>>> match used?
>> find-links are searched before the index
>
> Are all find-links searched, regardless of whether they're in  
> ~/.buildout/default.cfg or a buildout.cfg?
> (ie: what happens if both have find-links in them?)

For any option, if an option is defined in default.cfg and  
buildout.cfg, then the one in buildout.cfg overrides the one in  
default.cfg.  There is no implicit merging.


>>>> We simply set up an sftp server and point buildout at it using  
>>>> the buildoutsftp buildout extension and sftp urls, as in:
>>>> extensions = zc.buildoutsftp
>>>> find-links = sftp://private.zope.com/private
>>>> This provides restricted access with authentication using ssh keys.
>>>
>>> Cool. Out of interest, what ftp server do you use for this
>> The one built in to open ssh.
>
> So I assume the clients just have to be able to have their public  
> key on the sftp server?

Yes.  sftp is simply a file-transfer protocol implemented on top of ssh.

> Do you use specific keys for sftp

No

> or do the clients just have shell access on the server?

They don't necessarily have shell access. ssh lets you restrict what  
people can do. One downside of sftp is that it lets the user access  
any file on the system they have permissions for, so, for example,  
they can read any world-readable file.

Jim

--
Jim Fulton
Zope Corporation



From lists at zopyx.com  Sat Nov 15 15:57:44 2008
From: lists at zopyx.com (Andreas Jung)
Date: Sat, 15 Nov 2008 15:57:44 +0100
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <491EDC17.2000203@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk> <491ECF22.1060402@zopyx.com>
	<491EDC17.2000203@simplistix.co.uk>
Message-ID: <491EE368.3020404@zopyx.com>

On 15.11.2008 15:26 Uhr, Chris Withers wrote:
> Andreas Jung wrote:
>>> What I'd like to do is have a "local egg repository" that I can put
>>> these eggs in and then just point buildout at it.
>>
>> http://pypi.python.org/pypi/haufe.eggserver
>
> So you basically add the egg-server url as a find-links option?


Basically yes, we create an index page based on the content right now 
through cron - I will implement this functionality into haufe.eggserver 
soon.

>
> If you have a find-links in ~/.buildout/default.cfg, will that override
> or be combined with one in a buildout.cfg?

We have the URL of our internal eggserver within our buildout.cfg files.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081115/43ea7a02/attachment.vcf>

From philipp at weitershausen.de  Sat Nov 15 16:11:14 2008
From: philipp at weitershausen.de (Philipp von Weitershausen)
Date: Sat, 15 Nov 2008 16:11:14 +0100
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <491EDC17.2000203@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk> <491ECF22.1060402@zopyx.com>
	<491EDC17.2000203@simplistix.co.uk>
Message-ID: <491EE692.2050503@weitershausen.de>

Chris Withers wrote:
> Andreas Jung wrote:
>>> What I'd like to do is have a "local egg repository" that I can put
>>> these eggs in and then just point buildout at it.
>>
>> http://pypi.python.org/pypi/haufe.eggserver
> 
> So you basically add the egg-server url as a find-links option?

Actually, find-links won't replace the default location that 
easy_install/zc.buildout will go to when looking for eggs. It will only 
*enhance* the list of potentially installable packages.

If you want your buildout or easy_install to talk to a private package 
index *only*, you have to use the 'index' option (-i for easy_install), 
e.g.:

   [buildout]
   index = http://your/index   # can also be file:///...

> If you have a find-links in ~/.buildout/default.cfg, will that override 
> or be combined with one in a buildout.cfg?

It will be overridden if buildout.cfg specifies a find-links option as 
well. buildout.cfg can append to it, however:

   [buildout]
   ...
   find-links += some/more/stuff/here

From zooko at zooko.com  Sat Nov 15 20:42:05 2008
From: zooko at zooko.com (zooko)
Date: Sat, 15 Nov 2008 12:42:05 -0700
Subject: [Distutils] patch: solving the two major things that people dislike
	about setuptools, part 1
Message-ID: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>

Folks:

There are two things that cause a lot of people to object to the use
of setuptools: that it changes the semantics of PYTHONPATH, making it
impossible to override packages on the command-line, and that it
doesn't work when you run "setup.py install --prefix=./some_dir".

This patch addresses the first one. Currently, if you ever allow
setuptools to write into your system directory
(e.g. /usr/lib/python2.5/site-packages) then it will install a .pth
file which changes the behavior of PYTHONPATH.

This will prevent you from over-riding the installed package with a
specific package on the command-line, such as:

PYTHONPATH=./that-version-of-Twisted/ python ./my_script.py

Many people find this behavior of setuptools objectionable [1, 2, 3,
plus personal correspondance when I did my "Why do you hate
setuptools?" survey].  Fortunately it seems possible to preserve the
precedence of PYTHONPATH modules while still having installed eggs
override installed non-eggs, as motivated in [4].

Sat Nov 15 11:59:32 MST 2008  zooko at zooko.com
   * leave the PYTHONPATH dirs at the front of the sys.path
   This is in accordance with
   http://www.python.org/doc/2.5.2/inst/search-path.html , which says
   "The PYTHONPATH variable can be set to a list of paths that will be
   added to the beginning of sys.path.", and it resolves an objection
   many people have which impels them to ban setuptools from systems
   they administrate.
--- old-dw-0.6c9/setuptools/command/easy_install.py
+++ new-dw-0.6c9/setuptools/command/easy_install.py
@@ -1364,7 +1364,7 @@
                  "%s\n"
                  "import sys; new=sys.path[sys.__plen:];"
                  " del sys.path[sys.__plen:];"
-                " p=getattr(sys,'__egginsert',0); sys.path[p:p]=new;"
+                " p=getattr(sys,'__egginsert',len(os.environ.get 
('PYTHONPATH','').split(os.pathsep))); sys.path[p:p]=new;"
                  " sys.__egginsert = p+len(new)\n"
              ) % data



Regards,

Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $10/month

[1] http://mail.python.org/pipermail/distutils-sig/2006-July/006492.html
[2] https://www.dfwpython.org/pipermail/dfwpython/2007-June/000756.html
[3] http://www.rittau.org/blog/20070726-02
[4] http://mail.python.org/pipermail/python-dev/2008-March/077918.html

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081115/b178be45/attachment.txt>

From zooko at zooko.com  Sat Nov 15 20:59:25 2008
From: zooko at zooko.com (zooko)
Date: Sat, 15 Nov 2008 12:59:25 -0700
Subject: [Distutils] patch: solving the two major things that people dislike
	about setuptools, part 2
Message-ID: <35E1B486-2B4E-454E-8685-03354A1181F9@zooko.com>

Folks:

There are two things that cause a lot of people to object to the use
of setuptools: that it changes the semantics of PYTHONPATH, and that it
doesn't work when you run "setup.py install --prefix=somedir".

This pair of patches addresses the second issue: that when you run
"python ./setup.py install --prefix=somedir" it doesn't work like
distutils does.  It is possible to work-around this in various ways
(either with --svem --record or with mkdir -p and PYTHONPATH before
invoking setup.py) but the existence of these work-arounds does not
seem to be sufficient to make some people accept the use of setuptools
[1, 2, personal correspondance from my "Why do you hate setuptools?"
survey].

These patches make setuptools behave more like distutils in this
respect.

I know that you had good reason to do these sanity checks in the first
place, PJE, but I hope that you will consider accepting these patches
in order to extend setuptools's reach.

Sat Nov 15 12:04:20 MST 2008  zooko at zooko.com
   * try to mkdir the install directory
   This eases the common use case of "./setup.py install -- 
prefix=somedir"
   and makes setuptools behave more like distutils in this case.
--- old-dw-0.6c9/setuptools/command/easy_install.py
+++ new-dw-0.6c9/setuptools/command/easy_install.py
@@ -249,6 +249,14 @@
          instdir = normalize_path(self.install_dir)
          pth_file = os.path.join(instdir,'easy-install.pth')

+        # mkdir it if necessary
+        try:
+            os.makedirs(instdir)
+        except OSError:
+            # Oh well -- hopefully this error simply means that it  
is already there.
+            # If not the subsequent write test will identify the  
problem.
+            pass
+
          # Is it a configured, PYTHONPATH, implicit, or explicit  
site dir?
          is_site_dir = instdir in self.all_site_dirs


Sat Nov 15 12:05:01 MST 2008  zooko at zooko.com
   * change exception into warning when target install dir isn't pth- 
capable
   This eases the common use case of "./setup.py install --prefix=foo"
   followed by some other mechanism to make sure that ./foo/... is
   importable, and makes setuptools behave more like distutils in  
this regard.

--- old-dw-0.6c9/setuptools/command/easy_install.py
+++ new-dw-0.6c9/setuptools/command/easy_install.py
@@ -276,7 +276,7 @@

          if not is_site_dir and not self.multi_version:
              # Can't install non-multi to non-site dir
-            raise DistutilsError(self.no_default_version_msg())
+            log.warn(self.no_default_version_msg())

          if is_site_dir:
              if self.pth_file is None:
@@ -1059,7 +1059,9 @@

    http://peak.telecommunity.com/EasyInstall.html#custom- 
installation-locations

-Please make the appropriate changes for your system and try  
again.""" % (
+Proceeding to install.  Please remember that unless you make one of
+these changes you will not be able to run the installed code.
+""" % (
          self.install_dir, os.environ.get('PYTHONPATH','')
      )


Regards,

Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $10/month

[1] http://adam.gomaa.us/blog/easy-install-isnt/
[2] https://bugs.launchpad.net/pyopenssl/+bug/238658/comments/25


From tseaver at palladion.com  Sat Nov 15 21:11:06 2008
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 15 Nov 2008 15:11:06 -0500
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <491ECE7A.1020808@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk>
Message-ID: <491F2CDA.8030003@palladion.com>

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

Chris Withers wrote:
> Hi All,
> 
> I'm getting a growing number of customer-specific and non-open-source 
> eggs. I used to just put these in as svn:externals and then add the path 
> in as a develop egg, however, I'm not sure this is going to scale.
> 
> What I'd like to do is have a "local egg repository" that I can put 
> these eggs in and then just point buildout at it.
> 
> Has anyone done this before?
> 
> Failing that, is there any way in buildout to say "use this egg 
> repository in favour of pypi, and only look at pypi if the egg isn't 
> found in the local repository"?
> 
> Also, does anyone have any software that makes a good egg repository?
> 
> Does anyone have anything that supports the equivalent of:
> 
> python setup.py upload
> 
> ...but to a local repository?

The attached script makes an index from a directory full of
distributions.  We use it to create the indexes on dist.repoze.org, as
well as for customer-project-specific indexes.


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

iD8DBQFJHyzZ+gerLs4ltQ4RAj6uAJwI9460ChTKOaU1eYd+u/sverl8qACfWUjB
ofH4v/hcrFECvuf/19XFFsg=
=dulB
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makeindex.py
Type: application/x-httpd-cgi
Size: 4389 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081115/18a86cb2/attachment-0001.bin>

From gael.varoquaux at normalesup.org  Sat Nov 15 21:36:34 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 15 Nov 2008 21:36:34 +0100
Subject: [Distutils] patch: solving the two major things that
	people	dislike about setuptools, part 1
In-Reply-To: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
Message-ID: <20081115203634.GA8204@phare.normalesup.org>

On Sat, Nov 15, 2008 at 12:42:05PM -0700, zooko wrote:
> This patch addresses the first one. 

Very nice zooko.

Ga?l

From kiorky at cryptelium.net  Sun Nov 16 18:32:41 2008
From: kiorky at cryptelium.net (kiorky)
Date: Sun, 16 Nov 2008 18:32:41 +0100
Subject: [Distutils] pypi submission down?
Message-ID: <49205939.8060904@cryptelium.net>

I can't submit anymore dists for one of my eggs.

Pypi returns me HTTP/500 error either if i submit TTW or via sdist upload.

Am i alone to encounter the problem?

-- 
--
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081116/c3f4e614/attachment.pgp>

From chris at simplistix.co.uk  Mon Nov 17 08:11:18 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 17 Nov 2008 07:11:18 +0000
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <491EE368.3020404@zopyx.com>
References: <491ECE7A.1020808@simplistix.co.uk> <491ECF22.1060402@zopyx.com>
	<491EDC17.2000203@simplistix.co.uk> <491EE368.3020404@zopyx.com>
Message-ID: <49211916.90609@simplistix.co.uk>

Andreas Jung wrote:
>> So you basically add the egg-server url as a find-links option?
> 
> Basically yes, we create an index page based on the content right now 
> through cron - I will implement this functionality into haufe.eggserver 
> soon.

Out on interest, how does buildout handle password-protected indexes?

cheers,

Chris

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

From lists at zopyx.com  Mon Nov 17 08:13:42 2008
From: lists at zopyx.com (Andreas Jung)
Date: Mon, 17 Nov 2008 08:13:42 +0100
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <49211916.90609@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk> <491ECF22.1060402@zopyx.com>
	<491EDC17.2000203@simplistix.co.uk>
	<491EE368.3020404@zopyx.com> <49211916.90609@simplistix.co.uk>
Message-ID: <492119A6.7040704@zopyx.com>

On 17.11.2008 8:11 Uhr, Chris Withers wrote:
> Andreas Jung wrote:
>>> So you basically add the egg-server url as a find-links option?
>>
>> Basically yes, we create an index page based on the content right now
>> through cron - I will implement this functionality into
>> haufe.eggserver soon.
>
> Out on interest, how does buildout handle password-protected indexes?


Unsupported - we trust our internal and external developers.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081117/87d54ca6/attachment.vcf>

From chris at simplistix.co.uk  Mon Nov 17 08:17:09 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 17 Nov 2008 07:17:09 +0000
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <492119A6.7040704@zopyx.com>
References: <491ECE7A.1020808@simplistix.co.uk> <491ECF22.1060402@zopyx.com>
	<491EDC17.2000203@simplistix.co.uk>
	<491EE368.3020404@zopyx.com> <49211916.90609@simplistix.co.uk>
	<492119A6.7040704@zopyx.com>
Message-ID: <49211A75.109@simplistix.co.uk>

Andreas Jung wrote:
>> Out on interest, how does buildout handle password-protected indexes?
> 
> Unsupported - we trust our internal and external developers.

Okay, but surely that means you can only expose that packaging server to 
a very limited set of people? If you can upload and download without 
restriction, then at most you can only expose it to an intranet of 
machines that need packages (what do you do if they're on more than one 
site with no linking vpn?) and even for developers, I guess they must 
have to be attached to some vpn to upload packages? Still, how do you 
stop clients that should only be reading packages (which I'm guessing is 
the majority) from uploading rogue packages?

cheers,

Chris

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

From lists at zopyx.com  Mon Nov 17 08:24:28 2008
From: lists at zopyx.com (Andreas Jung)
Date: Mon, 17 Nov 2008 08:24:28 +0100
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <49211A75.109@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk> <491ECF22.1060402@zopyx.com>
	<491EDC17.2000203@simplistix.co.uk>
	<491EE368.3020404@zopyx.com> <49211916.90609@simplistix.co.uk>
	<492119A6.7040704@zopyx.com> <49211A75.109@simplistix.co.uk>
Message-ID: <49211C2C.80800@zopyx.com>

On 17.11.2008 8:17 Uhr, Chris Withers wrote:
> Andreas Jung wrote:
>>> Out on interest, how does buildout handle password-protected indexes?
>>
>> Unsupported - we trust our internal and external developers.
>
> Okay, but surely that means you can only expose that packaging server to
> a very limited set of people? If you can upload and download without
> restriction, then at most you can only expose it to an intranet of
> machines that need packages (what do you do if they're on more than one
> site with no linking vpn?) and even for developers, I guess they must
> have to be attached to some vpn to upload packages? Still, how do you
> stop clients that should only be reading packages (which I'm guessing is
> the majority) from uploading rogue packages?
>

The scope of haufe.eggserver is basically for internal development and 
deployment only. So here security does not matter. Eggbasket obviously 
provides support for restricting uploads on a per package basis as PyPI 
does. However I did not get Eggbasket running.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081117/8479f6b2/attachment.vcf>

From chris at simplistix.co.uk  Mon Nov 17 08:31:28 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 17 Nov 2008 07:31:28 +0000
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <49211C2C.80800@zopyx.com>
References: <491ECE7A.1020808@simplistix.co.uk> <491ECF22.1060402@zopyx.com>
	<491EDC17.2000203@simplistix.co.uk>
	<491EE368.3020404@zopyx.com> <49211916.90609@simplistix.co.uk>
	<492119A6.7040704@zopyx.com> <49211A75.109@simplistix.co.uk>
	<49211C2C.80800@zopyx.com>
Message-ID: <49211DD0.3090706@simplistix.co.uk>

Andreas Jung wrote:
> The scope of haufe.eggserver is basically for internal development and 
> deployment only. 

Even in that case, how do you shield it from people who could upload 
rogue packages?

> Eggbasket obviously 
> provides support for restricting uploads on a per package basis as PyPI 
> does. However I did not get Eggbasket running.

Which Eggbasket are you referring to? I found one from the grok guys, 
one which claimed to be a re-implementation of your egg server, and I 
have a nagging feeling that ChrisM or Tres had something of that name too...

cheers,

Chris

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

From kiorky at cryptelium.net  Mon Nov 17 08:33:26 2008
From: kiorky at cryptelium.net (kiorky)
Date: Mon, 17 Nov 2008 08:33:26 +0100
Subject: [Distutils] pypi submission down?
In-Reply-To: <49205939.8060904@cryptelium.net>
References: <49205939.8060904@cryptelium.net>
Message-ID: <49211E46.7040802@cryptelium.net>

kiorky a ?crit :
> I can't submit anymore dists for one of my eggs.
> 
> Pypi returns me HTTP/500 error either if i submit TTW or via sdist upload.
> 
> Am i alone to encounter the problem?
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
Uhm, i was used to do --formats=zip when uploading.
It's failing now if i force the format to zip (i encounter some problems with
tar, so i prefer to provide zip for my dists).

The package failing with zip can be cloned with:
hg clone http://hg.minitage.org/minitage/eggs/minitage.core

If someone has a clue why now it 's doesn't work anymore with zip dists...

-- 
--
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081117/39956594/attachment-0001.pgp>

From ziade.tarek at gmail.com  Mon Nov 17 09:04:05 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 17 Nov 2008 09:04:05 +0100
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <492119A6.7040704@zopyx.com>
References: <491ECE7A.1020808@simplistix.co.uk> <491ECF22.1060402@zopyx.com>
	<491EDC17.2000203@simplistix.co.uk> <491EE368.3020404@zopyx.com>
	<49211916.90609@simplistix.co.uk> <492119A6.7040704@zopyx.com>
Message-ID: <94bdd2610811170004h5fc7ebdeyc9f7a6a1cfdde3ad@mail.gmail.com>

On Mon, Nov 17, 2008 at 8:13 AM, Andreas Jung <lists at zopyx.com> wrote:
> On 17.11.2008 8:11 Uhr, Chris Withers wrote:
>>
>> Andreas Jung wrote:
>>>>
>>>> So you basically add the egg-server url as a find-links option?
>>>
>>> Basically yes, we create an index page based on the content right now
>>> through cron - I will implement this functionality into
>>> haufe.eggserver soon.
>>
>> Out on interest, how does buildout handle password-protected indexes?
>
>
> Unsupported - we trust our internal and external developers.
>

Not quite true, you can.

-> use lovely.httprequest and you're set (it does authentication for
any pypi compatible  server as long as you
add a .httpauth file)


Cheers

From ziade.tarek at gmail.com  Mon Nov 17 09:05:42 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 17 Nov 2008 09:05:42 +0100
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <94bdd2610811170004h5fc7ebdeyc9f7a6a1cfdde3ad@mail.gmail.com>
References: <491ECE7A.1020808@simplistix.co.uk> <491ECF22.1060402@zopyx.com>
	<491EDC17.2000203@simplistix.co.uk> <491EE368.3020404@zopyx.com>
	<49211916.90609@simplistix.co.uk> <492119A6.7040704@zopyx.com>
	<94bdd2610811170004h5fc7ebdeyc9f7a6a1cfdde3ad@mail.gmail.com>
Message-ID: <94bdd2610811170005s2a118e2fhabb32310992ecc52@mail.gmail.com>

On Mon, Nov 17, 2008 at 9:04 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> On Mon, Nov 17, 2008 at 8:13 AM, Andreas Jung <lists at zopyx.com> wrote:
>> On 17.11.2008 8:11 Uhr, Chris Withers wrote:
>>>
>>> Andreas Jung wrote:
>>>>>
>>>>> So you basically add the egg-server url as a find-links option?
>>>>
>>>> Basically yes, we create an index page based on the content right now
>>>> through cron - I will implement this functionality into
>>>> haufe.eggserver soon.
>>>
>>> Out on interest, how does buildout handle password-protected indexes?
>>
>>
>> Unsupported - we trust our internal and external developers.
>>
>
> Not quite true, you can.
>
> -> use lovely.httprequest and you're set (it does authentication for
> any pypi compatible  server as long as you
> add a .httpauth file)
>
>
> Cheers
>

oups sorry, typo -> lovely.buildouthttp

http://pypi.python.org/pypi/lovely.buildouthttp




-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/

From raul at dervishd.net  Mon Nov 17 11:59:58 2008
From: raul at dervishd.net (=?UTF-8?B?UmHDumwgTsO6w7Fleg==?= de Arenas Coronado)
Date: Mon, 17 Nov 2008 11:59:58 +0100
Subject: [Distutils] Honoring localedir
Message-ID: <20081117115958.4e8d5d4f@DervishD>

Hi all :)

I would like to support options like "--localedir" in my setup.py, and
that means:

- Support the option in setup.py. Easy, just subclassing and appending
  the option to the proper "user_options". Worst part is that I would
  have to subclass both "build_scripts" and "install_data" for this to
  work. More on that below.

- Changing the hardcoded path into the main script, so the proper path
  is given to "bindtextdomain()". I suppose I have to subclass
  "build_scripts" for this, run sed or whatever to modify the script
  code with the specified paths, etc.

- Install the files to the user-specified location. This means I have to
  subclass "install_data" for this, to put the translation files where
  the end-user wants me to do.

At first I was ready to do the above, but then I thought of a big
problem (I'm used to autoconf's './configure', and this problem doesn't
happens with it): the end-user may run, by mistake, "setup.py build
--localedir=mylocaledir" first and "setup.py install" after that, and
that means that the script will look for the translations into
"mylocaledir", but translations will be installed in
"/usr/share/locale", probably.

Then I thought: no problem. I won't touch any "build" subclass and will
do the modifications at installation time, subclassing only
"install_scripts" and "install_data". Then again, both commands are
independent and if the user forgets to pass "--localedir" to any of
them, the installed script won't work properly.

The same problem happens with any data that the script have to access
and whose path can be only determined at installation time (icons, for
example).

Right now I only have these choices, if using distutils:

- Forget "--localedir" and use the default options (--install-data, for
  example). This doesn't solve my problem, because as soon as the user
  installs the program using separate "install_scripts" and
  "install_data" commands, it's impossible to put the proper directory
  into the script because the destination directory for data files won't
  be known when installing the scripts.

- Use hardcoded, FHS compliants directories for translations and icons,
  and hope that new data types I may need in the future have such FHS
  compliant directories. This means that my script will try to find the
  data in /usr/whatever and /usr/local/whatever (and maybe under
  /opt/package/whatever), so any installation outside those directories
  won't work. This looks like the more frequent solution, from what I've
  googled.

- Use a self made "setup.py" that doesn't use distutils at all.
  Tempting, but right now I'm not like reinventing wheels. Moreover,
  I've already read half of the code of distutils to know what to
  subclass and how, and I would like to use distutils if possible.


So, my question is: is there any "official" way of doing what I want?
That is, treating the script as a template and put the proper paths
there, no matter what combination of "build_*" and "install_*" commands
are used. I could live by using hardcoded paths, but that's not the way
I've done things in the past (when using autoconf, CMake, MOBS, etc.)
and I don't feel comfortable with it.

I've googled with no result, and I'm afraid that people use hardcoded
paths or their own search functions to find the data once it is
installed.

Thanks a lot in advance :)

Ra?l "DervishD" N??ez de Arenas Coronado
-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
We are waiting for 13 Feb 2009 23:31:30 +0000 ...

From chris at simplistix.co.uk  Mon Nov 17 18:34:05 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 17 Nov 2008 17:34:05 +0000
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <B575ECAD-2B8B-49C8-ABE3-E62EC7C59BA2@zope.com>
References: <491ECE7A.1020808@simplistix.co.uk>
	<B575ECAD-2B8B-49C8-ABE3-E62EC7C59BA2@zope.com>
Message-ID: <4921AB0D.2090701@simplistix.co.uk>

Jim Fulton wrote:
> 
> We simply set up an sftp server and point buildout at it using the 
> buildoutsftp buildout extension and sftp urls, as in:
> 
>   extensions = zc.buildoutsftp
>   find-links = sftp://private.zope.com/private

Incidentally, the docs at http://pypi.python.org/pypi/zc.buildoutsftp 
contain a rather crucial bug by saying extension rather than extensions ;-)

Also slight annoyance that pycrypto doesn't have a win32 egg :-(
How did you get around this?

Chris

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

From jorge.vargas at gmail.com  Tue Nov 18 10:56:49 2008
From: jorge.vargas at gmail.com (Jorge Vargas)
Date: Tue, 18 Nov 2008 03:56:49 -0600
Subject: [Distutils] setuptools Windows installer for Python 2.6
In-Reply-To: <OFCE97B2C1.DD3FDB34-ON652574FE.0036B825-652574FE.0036E9B4@in.ibm.com>
References: <OFCE97B2C1.DD3FDB34-ON652574FE.0036B825-652574FE.0036E9B4@in.ibm.com>
Message-ID: <32822fe60811180156lf3e8785na80c7f46bc1d4082@mail.gmail.com>

2008/11/11 Abhigyan Agrawal1 <abhigyan_agrawal at in.ibm.com>:
>
> Hi,
>         I am wondering if there is any plan to release a windows installer
> for setuptools setup for Python 2.6?
>
if you build it yourself.
$ python setup.py bdist_egg
and make sure everything runs fine, then post it. it should be done faster.

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

From kalkidan5033 at yahoo.com  Tue Nov 18 11:36:09 2008
From: kalkidan5033 at yahoo.com (Kalkidan Aweke)
Date: Tue, 18 Nov 2008 02:36:09 -0800 (PST)
Subject: [Distutils] question about python
Message-ID: <619800.61393.qm@web36102.mail.mud.yahoo.com>

Dear sir/maddam
I am using python Release 2.3.3, but I cant use it solving the following? python source code. Would you please help me in solving the following problem using some other python release.
Exponentiation
Consider the following Python code: def expo(s,lm,N):? return reduce(lambda x,m: pow(x,m,N),lm,s)?def hamming(a):? return a>0 and (a%2)+hamming(a/2) or 0?def htot(k):? n=pow(2,k)? N=pow(2,n)-3? lm=[pow(i,i,N) for i in range(1,n+1)]? lz=[expo(3,lm[:j]+lm[j+1:],N) for j in range(n)]? return sum([hamming(z) for z in lz])
The function htot gives the following result for small values of k: >>>? [htot(i) for i in range(3,8)][35, 122L, 540L, 2068L, 8070L]
You are scincerely?asked to compute the value of function htot for larger values of k. Go as far as you can.? 
I am expecting your fast respond.
?
?
With Best Regards.
?
?
Kalkidan Aweke
+251911505062
Addis Ababa
Ethiopia


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081118/1a4c2003/attachment.htm>

From jaraco at jaraco.com  Tue Nov 18 15:53:11 2008
From: jaraco at jaraco.com (Jason R. Coombs)
Date: Tue, 18 Nov 2008 07:53:11 -0700
Subject: [Distutils] new behavior of parse_version('dev')?
Message-ID: <750B64C66078B34D918257A1AC004DB205461A@messiah.jaraco.com>

It appears to me as if the behavior of parse_version('dev') has changed with
setuptools-0.6c9, but this change is not documented on the setuptools
documentation.  Assuming pv=parse_version, the documentation implies that
pv('a') < pv('b') < pv('c') == pv('rc') < pv('d') == pv('dev'). but it turns
out that pv('dev') == pv('@') < pv('a').

 

I suggest the documentation say something like the following:

 

A pre-release tag is a series of letters that are alphabetically before
"final". Some examples of prerelease tags would include alpha, beta, a, c,
dev, and so on. You do not have to place a dot before the prerelease tag if
it's immediately after a number, but it's okay to do so if you prefer. Thus,
2.4c1 and 2.4.c1 both represent release candidate 1 of version 2.4, and are
treated as identical by setuptools.

In addition, there are three special prerelease tags that are treated as if
they were the letter c: pre, preview, and rc. So, version 2.4rc1, 2.4pre1
and 2.4preview1 are all the exact same version as 2.4c1, and are treated as
identical by setuptools.

Furthermore, dev is a special tag that is always less than any other
character tag.  It is treated as the equivalent of the character '@'.

Any objections?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081118/edf0418c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7001 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081118/edf0418c/attachment.bin>

From peter at fry-it.com  Wed Nov 19 00:27:37 2008
From: peter at fry-it.com (Peter Bengtsson)
Date: Tue, 18 Nov 2008 23:27:37 +0000
Subject: [Distutils] Seems to work except it won't import
Message-ID: <bc95c2800811181527j2ef849ecw94ba4ecb728904bc@mail.gmail.com>

Sorry about the vague subject but I'm not sure how to phrase my problem.
First of all I'm a setuptools beginner and I'm not sure what I'm doing.

I've created a basic package with paster and filled in the blanks. Now
python setup.py test works and runs the two little tests it has.
I might have "pressed one too many buttons" when I ran setup.py which
might be why it doesn't work.

It's available on http://pypi.python.org/pypi/domstripper/

But when I do this:

(my_virtualenv)$ easy_install domstripper
...
(my_virtualenv)$ ls lib/python2.5/site-packages/
lxml-2.1.3-py2.5-linux-i686.egg
domstripper-0.2dev_r16670-py2.5.egg
setuptools-0.6c8-py2.5.egg
easy-install.pth
setuptools.pth


it installs fine as far as I can see but here's the problem::
 (my_virtualenv) $ python
 >>> import lxml # just to test that something worked
 >>> import domstripper

Grateful for advice.



-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com

From peter at fry-it.com  Wed Nov 19 00:34:30 2008
From: peter at fry-it.com (Peter Bengtsson)
Date: Tue, 18 Nov 2008 23:34:30 +0000
Subject: [Distutils] Seems to work except it won't import
In-Reply-To: <bc95c2800811181527j2ef849ecw94ba4ecb728904bc@mail.gmail.com>
References: <bc95c2800811181527j2ef849ecw94ba4ecb728904bc@mail.gmail.com>
Message-ID: <bc95c2800811181534n3d9a2a5ct1e6fb749793b6da8@mail.gmail.com>

>
> it installs fine as far as I can see but here's the problem::
>  (my_virtualenv) $ python
>  >>> import lxml # just to test that something worked
>  >>> import domstripper
>
If it wasn't clear, this is where I get an ImportError::

  >>> import domstripper
  Traceback (most recent call last):
  ...
  ImportError: No module named domstripper


-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com

From pje at telecommunity.com  Wed Nov 19 04:47:52 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 18 Nov 2008 22:47:52 -0500
Subject: [Distutils] Seems to work except it won't import
In-Reply-To: <bc95c2800811181527j2ef849ecw94ba4ecb728904bc@mail.gmail.co
 m>
References: <bc95c2800811181527j2ef849ecw94ba4ecb728904bc@mail.gmail.com>
Message-ID: <20081119034625.368613A40A0@sparrow.telecommunity.com>

Your __init__.py and domstripper.py need to be moved into a 
subdirectory named domstripper.


At 11:27 PM 11/18/2008 +0000, Peter Bengtsson wrote:
>Sorry about the vague subject but I'm not sure how to phrase my problem.
>First of all I'm a setuptools beginner and I'm not sure what I'm doing.
>
>I've created a basic package with paster and filled in the blanks. Now
>python setup.py test works and runs the two little tests it has.
>I might have "pressed one too many buttons" when I ran setup.py which
>might be why it doesn't work.
>
>It's available on http://pypi.python.org/pypi/domstripper/
>
>But when I do this:
>
>(my_virtualenv)$ easy_install domstripper
>...
>(my_virtualenv)$ ls lib/python2.5/site-packages/
>lxml-2.1.3-py2.5-linux-i686.egg
>domstripper-0.2dev_r16670-py2.5.egg
>setuptools-0.6c8-py2.5.egg
>easy-install.pth
>setuptools.pth
>
>
>it installs fine as far as I can see but here's the problem::
>  (my_virtualenv) $ python
>  >>> import lxml # just to test that something worked
>  >>> import domstripper
>
>Grateful for advice.


From peter at fry-it.com  Wed Nov 19 10:02:15 2008
From: peter at fry-it.com (Peter Bengtsson)
Date: Wed, 19 Nov 2008 09:02:15 +0000
Subject: [Distutils] Seems to work except it won't import
In-Reply-To: <20081119034625.368613A40A0@sparrow.telecommunity.com>
References: <bc95c2800811181527j2ef849ecw94ba4ecb728904bc@mail.gmail.com>
	<20081119034625.368613A40A0@sparrow.telecommunity.com>
Message-ID: <bc95c2800811190102r89fdc3bpf5f32a1757b7853@mail.gmail.com>

2008/11/19 Phillip J. Eby <pje at telecommunity.com>:
> Your __init__.py and domstripper.py need to be moved into a subdirectory
> named domstripper.
>
It works now! Thanks!
It confused me when that directory was created after setting up the package.

>
> At 11:27 PM 11/18/2008 +0000, Peter Bengtsson wrote:
>>
>> Sorry about the vague subject but I'm not sure how to phrase my problem.
>> First of all I'm a setuptools beginner and I'm not sure what I'm doing.
>>
>> I've created a basic package with paster and filled in the blanks. Now
>> python setup.py test works and runs the two little tests it has.
>> I might have "pressed one too many buttons" when I ran setup.py which
>> might be why it doesn't work.
>>
>> It's available on http://pypi.python.org/pypi/domstripper/
>>
>> But when I do this:
>>
>> (my_virtualenv)$ easy_install domstripper
>> ...
>> (my_virtualenv)$ ls lib/python2.5/site-packages/
>> lxml-2.1.3-py2.5-linux-i686.egg
>> domstripper-0.2dev_r16670-py2.5.egg
>> setuptools-0.6c8-py2.5.egg
>> easy-install.pth
>> setuptools.pth
>>
>>
>> it installs fine as far as I can see but here's the problem::
>>  (my_virtualenv) $ python
>>  >>> import lxml # just to test that something worked
>>  >>> import domstripper
>>
>> Grateful for advice.
>
>



-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com

From chris at simplistix.co.uk  Wed Nov 19 17:03:25 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 19 Nov 2008 16:03:25 +0000
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <4921AB0D.2090701@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk>	<B575ECAD-2B8B-49C8-ABE3-E62EC7C59BA2@zope.com>
	<4921AB0D.2090701@simplistix.co.uk>
Message-ID: <492438CD.9050605@simplistix.co.uk>

Chris Withers wrote:
> Also slight annoyance that pycrypto doesn't have a win32 egg :-(
> How did you get around this?

Well, no answer from Jim or pycrypto's maintainer. I eventually found these:

http://www.voidspace.org.uk/python/modules.shtml#pycrypto

Manually installing first lets zc.buildoutsftp install, however, 
whenever I run buildout:

- I still get the following warning whenever I run buildout:

Download error: unknown url type: sftp -- Some packages may not be found!

   Is that expected?

- pycrypto likes to be pretty verbose:

paramiko.transport: Connected (version 2.0, client OpenSSH_3.9p1)
paramiko.transport: Authentication (publickey) failed.
paramiko.transport: Connected (version 2.0, client OpenSSH_3.9p1)
paramiko.transport: Authentication (publickey) successful!
paramiko.transport: Secsh channel 1 opened.
paramiko.transport.sftp: [chan 1] Opened sftp connection (server version 3)

   Any way to shut this up?

- most seriously, buildout now seems to hang when it's almost done. I'm 
guessing this is the same windows-specific behaviour I mentioned before 
(seems to be to do with spawned processes) although this one is onyl 
escaped from with a Ctrl-C. Anyone else seen this?

cheers,

Chris

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

From jim at zope.com  Wed Nov 19 18:49:36 2008
From: jim at zope.com (Jim Fulton)
Date: Wed, 19 Nov 2008 12:49:36 -0500
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <492438CD.9050605@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk>	<B575ECAD-2B8B-49C8-ABE3-E62EC7C59BA2@zope.com>
	<4921AB0D.2090701@simplistix.co.uk>
	<492438CD.9050605@simplistix.co.uk>
Message-ID: <FD521BE4-470C-4176-9652-A1DBEF07274E@zope.com>


On Nov 19, 2008, at 11:03 AM, Chris Withers wrote:

> Chris Withers wrote:
>> Also slight annoyance that pycrypto doesn't have a win32 egg :-(
>> How did you get around this?
>
> Well, no answer from Jim or pycrypto's maintainer. I eventually  
> found these:

I didn't notice that message.

>
>
> http://www.voidspace.org.uk/python/modules.shtml#pycrypto
>
> Manually installing first lets zc.buildoutsftp install, however,  
> whenever I run buildout:
>
> - I still get the following warning whenever I run buildout:
>
> Download error: unknown url type: sftp -- Some packages may not be  
> found!
>
>  Is that expected?

Yes.  It's looking for the latest version of the extension, which it  
needs to interpret sftp links. :)

> - pycrypto likes to be pretty verbose:
>
> paramiko.transport: Connected (version 2.0, client OpenSSH_3.9p1)
> paramiko.transport: Authentication (publickey) failed.
> paramiko.transport: Connected (version 2.0, client OpenSSH_3.9p1)
> paramiko.transport: Authentication (publickey) successful!
> paramiko.transport: Secsh channel 1 opened.
> paramiko.transport.sftp: [chan 1] Opened sftp connection (server  
> version 3)
>
>  Any way to shut this up?

You can make buildout quieter, which just raises the overall logging  
threshold.

It might be interesting to see if the buildoutsftp extension could set  
the logging level of the paramiko logger to be different but relative  
to the top-level logging level.

> - most seriously, buildout now seems to hang when it's almost done.  
> I'm guessing this is the same windows-specific behaviour I mentioned  
> before (seems to be to do with spawned processes) although this one  
> is onyl escaped from with a Ctrl-C. Anyone else seen this?

No.  But a colleague reports hanging on resource-challenged VMs.   
There might be a resource issue affecting you.

One lamosity of buildoutsftp is that it makes a separate ssh  
connection for each fetch it does and it doesn't clean them up.  One  
of these days, I need to go back and implement a connection pool for it.

Jim

--
Jim Fulton
Zope Corporation



From chris at simplistix.co.uk  Wed Nov 19 18:59:20 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Wed, 19 Nov 2008 17:59:20 +0000
Subject: [Distutils] [buildout] private eggs and egg repositories
In-Reply-To: <FD521BE4-470C-4176-9652-A1DBEF07274E@zope.com>
References: <491ECE7A.1020808@simplistix.co.uk>	<B575ECAD-2B8B-49C8-ABE3-E62EC7C59BA2@zope.com>
	<4921AB0D.2090701@simplistix.co.uk>
	<492438CD.9050605@simplistix.co.uk>
	<FD521BE4-470C-4176-9652-A1DBEF07274E@zope.com>
Message-ID: <492453F8.9060706@simplistix.co.uk>

Jim Fulton wrote:
> 
>> Well, no answer from Jim or pycrypto's maintainer. I eventually found 
>> these:
> 
> I didn't notice that message.

No worries, so I take it you guys do just install pycrypto manually on 
Windows?

>> - I still get the following warning whenever I run buildout:
>>
>> Download error: unknown url type: sftp -- Some packages may not be found!
>>
>>  Is that expected?
> 
> Yes.  It's looking for the latest version of the extension, which it 
> needs to interpret sftp links. :)

That's a shame :-S I guess it's a bit chicken'n'egg, pardon the pun...
So, safe to ignore though, right?

> It might be interesting to see if the buildoutsftp extension could set 
> the logging level of the paramiko logger to be different but relative to 
> the top-level logging level.

I guess just bumping up the log level on that specific logger should be 
pretty easy and not really have any side effects.

>> - most seriously, buildout now seems to hang when it's almost done. 
>> I'm guessing this is the same windows-specific behaviour I mentioned 
>> before (seems to be to do with spawned processes) although this one is 
>> onyl escaped from with a Ctrl-C. Anyone else seen this?
> 
> No.  But a colleague reports hanging on resource-challenged VMs.  There 
> might be a resource issue affecting you.

It's a "real machine" with not a lot else going on so I'd be surprised :-S

cheers,

Chris

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

From chris at simplistix.co.uk  Thu Nov 20 09:06:08 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 20 Nov 2008 08:06:08 +0000
Subject: [Distutils] [buildout] private eggs and egg repositories - my
 current solution
In-Reply-To: <491ECE7A.1020808@simplistix.co.uk>
References: <491ECE7A.1020808@simplistix.co.uk>
Message-ID: <49251A70.6040508@simplistix.co.uk>

Chris Withers wrote:
> I'm getting a growing number of customer-specific and non-open-source 
> eggs. I used to just put these in as svn:externals and then add the path 
> in as a develop egg, however, I'm not sure this is going to scale.

Well, the solution I'm currently going with actually turned out to be 
rather simple:

- upload the eggs into a /eggs folder in the customer's svn repository
   (maybe clunky, but it's the easiest way I have of getting a password
    protected, served over https and mirrored between production and dr
    setuptools-compatible index)

- add the following to the buildouts:

[buildout]
extensions=lovely.buildouthttp
find-links=https://server/svn/eggs/

- put the appropriate entry in ~/.buildout/.httpauth

Hope this helps someone else in the same situation...

cheers,

Chris

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

From chris at simplistix.co.uk  Thu Nov 20 13:43:26 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 20 Nov 2008 12:43:26 +0000
Subject: [Distutils] bootstrap.py doesn't work offline?
Message-ID: <49255B6E.2090306@simplistix.co.uk>

Hi All,

Is it just me or does buildout's bootstrap.py not work offline, even if 
the latest versions of buildout and setuptools are available in 
buildout:egg-directory?

cheers,

Chris

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

From jim at zope.com  Thu Nov 20 16:29:42 2008
From: jim at zope.com (Jim Fulton)
Date: Thu, 20 Nov 2008 10:29:42 -0500
Subject: [Distutils] bootstrap.py doesn't work offline?
In-Reply-To: <49255B6E.2090306@simplistix.co.uk>
References: <49255B6E.2090306@simplistix.co.uk>
Message-ID: <6BC22EFF-A93C-4FFE-A0C0-C5F5A293F609@zope.com>


On Nov 20, 2008, at 7:43 AM, Chris Withers wrote:

> Hi All,
>
> Is it just me or does buildout's bootstrap.py not work offline, even  
> if the latest versions of buildout and setuptools are available in  
> buildout:egg-directory?

It isn't intended to work offline.

If you want to bootstrap a new buildout and have an existing buildout,  
you can use the existing buildout's buildout script to bootstrap the  
new buildout using the bootstrap command:

    path_to_some_other_buildout/bin/buildout bootstrap

This is what I normally do since it is much faster than running  
bootstrap.py.

Jim

--
Jim Fulton
Zope Corporation



From marius at pov.lt  Thu Nov 20 16:09:18 2008
From: marius at pov.lt (Marius Gedminas)
Date: Thu, 20 Nov 2008 17:09:18 +0200
Subject: [Distutils] bootstrap.py doesn't work offline?
In-Reply-To: <49255B6E.2090306@simplistix.co.uk>
References: <49255B6E.2090306@simplistix.co.uk>
Message-ID: <20081120150918.GA9399@fridge.pov.lt>

On Thu, Nov 20, 2008 at 12:43:26PM +0000, Chris Withers wrote:
> Is it just me or does buildout's bootstrap.py not work offline, even if 
> the latest versions of buildout and setuptools are available in 
> buildout:egg-directory?

That's right.  bootstrap.py is essentially

   exec urllib.urlopen('http://someplace/somescript').read().

I was scared too when I first saw it.

But you don't need bootstrap.py if you already have buildout installed.

Marius Gedminas
-- 
Linux: The Ultimate NT Service Pack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081120/69e20a81/attachment.pgp>

From tarek.ziade at ingeniweb.com  Thu Nov 20 16:54:37 2008
From: tarek.ziade at ingeniweb.com (Tarek Ziade)
Date: Thu, 20 Nov 2008 16:54:37 +0100
Subject: [Distutils] bootstrap.py doesn't work offline?
In-Reply-To: <20081120150918.GA9399@fridge.pov.lt>
References: <49255B6E.2090306@simplistix.co.uk>
	<20081120150918.GA9399@fridge.pov.lt>
Message-ID: <a26746990811200754t2f5322a0y3e853f83b6b9edd1@mail.gmail.com>

We have a special bootstrap.py here that will look for setuptools and other
on eggs/  in the buildout
or copy them from the system, so it works offline as well in case teh web is
unreachable.

Since bootstrap is also used to create directories inside the buildout or
simply, to link your buildout to another
interpreter, we wanted it to work with or without an internet connection.
(because you might want to run it again when you deploy
a source buildout at your customer in an existing python environment)

It is really simple to change.

2008/11/20 Marius Gedminas <marius at pov.lt>

> On Thu, Nov 20, 2008 at 12:43:26PM +0000, Chris Withers wrote:
> > Is it just me or does buildout's bootstrap.py not work offline, even if
> > the latest versions of buildout and setuptools are available in
> > buildout:egg-directory?
>
> That's right.  bootstrap.py is essentially
>
>   exec urllib.urlopen('http://someplace/somescript').read(<http://someplace/somescript%27%29.read%28>
> ).
>
> I was scared too when I first saw it.
>
> But you don't need bootstrap.py if you already have buildout installed.
>
> Marius Gedminas
> --
> Linux: The Ultimate NT Service Pack
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJJX2ekVdEXeem148RAkj7AJ9lxaTqzZK1vycCrtBZRWBHkDJfbwCfblGW
> dG9ERZAOYprXkEVnQudz4uI=
> =98yL
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>


-- 
Tarek Ziad? - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - B?timent D - 9?me ?tage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une soci?t? du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081120/5f7e24af/attachment.htm>

From chris at simplistix.co.uk  Fri Nov 21 09:49:04 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 21 Nov 2008 08:49:04 +0000
Subject: [Distutils] namespace packages question
Message-ID: <49267600.3020704@simplistix.co.uk>

Hi All,

I want to be able to do things such as:

from mortar import content
from mortar.sqlalchemy import storage

...but where mortar is distrubuted as one package and mortar.sqlalchemy 
(and a whole lot more like it...) are distributed as seperate packages.

Is this possible?

cheers,

Chris

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

From mal at egenix.com  Fri Nov 21 14:26:12 2008
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 21 Nov 2008 14:26:12 +0100
Subject: [Distutils] namespace packages question
In-Reply-To: <49267600.3020704@simplistix.co.uk>
References: <49267600.3020704@simplistix.co.uk>
Message-ID: <4926B6F4.6070002@egenix.com>

On 2008-11-21 09:49, Chris Withers wrote:
> Hi All,
> 
> I want to be able to do things such as:
> 
> from mortar import content
> from mortar.sqlalchemy import storage
> 
> ...but where mortar is distrubuted as one package and mortar.sqlalchemy
> (and a whole lot more like it...) are distributed as seperate packages.
> 
> Is this possible?

Sure. We've been doing just that for years with our mx Base package
and the mxODBC and mx Experimental add-ons for it.

All you have to do is put the base package into the first setup.py
and the subpackages in all others.

When installing these, distutils and all the binary installers for it
will happily combine everything into the final version of your
package on the target machine.

An alternative would be creating separate packages for all
components and then having the base package import all of them
on demand using e.g. the LazyModule object we have in eGenix mx
Base (it's in mx.Misc.LazyModule).

Yet another way is using __path__ hacks such as the one from setuptools,
but that can have serious implications on the import and startup time
of your app.

Finally, you could add you own importer to go hunt for the
other installed subpackages and install that at base package
import time.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 21 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2008-11-12: Released mxODBC.Connect 0.9.3      http://python.egenix.com/

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


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

From setuptools at bugs.python.org  Fri Nov 21 17:53:41 2008
From: setuptools at bugs.python.org (Zooko O'Whielacronx)
Date: Fri, 21 Nov 2008 16:53:41 +0000
Subject: [Distutils] [issue53] respect the PYTHONPATH
In-Reply-To: <1227286421.52.0.213538586193.issue53@psf.upfronthosting.co.za>
Message-ID: <1227286421.52.0.213538586193.issue53@psf.upfronthosting.co.za>


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

Here is a patch to let elements of the PYTHONPATH environment variable maintain
precedence with regard to installed eggs, while still allowing installed eggs to
maintain their precedence with regard to installed non-eggs:

http://mail.python.org/pipermail/distutils-sig/2008-November/010487.html

----------
messages: 205
nosy: zooko
priority: feature
status: unread
title: respect the PYTHONPATH

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

From setuptools at bugs.python.org  Fri Nov 21 18:08:49 2008
From: setuptools at bugs.python.org (Zooko O'Whielacronx)
Date: Fri, 21 Nov 2008 17:08:49 +0000
Subject: [Distutils] [issue54] be more like distutils with regard to
	--prefix=
In-Reply-To: <1227287329.2.0.788753241799.issue54@psf.upfronthosting.co.za>
Message-ID: <1227287329.2.0.788753241799.issue54@psf.upfronthosting.co.za>


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

Here is a patch to create --prefix= subtree if it doesn't already exist and
another patch to treat "that's not on the sys.path" as a warning instead of a
hard error.  This fixes one of the most common complaints that I heard when I
asked a bunch of people who refused to use setuptools why they refused to use it.

----------
files: mkdir.patch.txt
messages: 206
nosy: zooko
priority: feature
status: unread
title: be more like distutils with regard to --prefix=
Added file: http://bugs.python.org/setuptools/file26/mkdir.patch.txt

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue54>
_______________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mkdir.patch.txt
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081121/c76454f4/attachment.txt>

From setuptools at bugs.python.org  Sun Nov 23 03:06:21 2008
From: setuptools at bugs.python.org (Philip Jenvey)
Date: Sun, 23 Nov 2008 02:06:21 +0000
Subject: [Distutils] [issue55] [PATCH] Jython api_tests.txt doctest
	compatibility
In-Reply-To: <1227405980.94.0.350193269962.issue55@psf.upfronthosting.co.za>
Message-ID: <1227405980.94.0.350193269962.issue55@psf.upfronthosting.co.za>


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

Jython recently fixed an issue where __file__ would never use the compiled name 
(i.e. pkg_resources$py.class instead of pkg_resources.py). This exposed a small 
incompat. in the api_tests.txt

Patch attached

----------
assignedto: pje
files: api_tests-jython-fix_r67347.diff
messages: 208
nosy: pje, pjenvey
priority: bug
status: unread
title: [PATCH] Jython api_tests.txt doctest compatibility
Added file: http://bugs.python.org/setuptools/file28/api_tests-jython-fix_r67347.diff

_______________________________________________
Setuptools tracker <setuptools at bugs.python.org>
<http://bugs.python.org/setuptools/issue55>
_______________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: api_tests-jython-fix_r67347.diff
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081123/e59cef79/attachment.txt>

From vschmidt at ccom.unh.edu  Mon Nov 24 17:55:04 2008
From: vschmidt at ccom.unh.edu (Val Schmidt)
Date: Mon, 24 Nov 2008 11:55:04 -0500
Subject: [Distutils] Using setuptools
Message-ID: <E9C41DF1-A285-442F-AE6A-BA608F316C41@ccom.unh.edu>

Hi,

1) When running 'setup.py bdist_egg' the subdirectories build/ and  
dists/ are created. Do people typically add and mange these  
directories and their contents within subversion as well? Or do you  
typically have a separate place, outside of your subversion sandbox  
for building distributions?

2) I'm using epydoc to generate documentation for my module. Is it  
appropriate to include the resulting html/ directory and it's contents  
in the egg in some way and if so, how?

-Val




------------------------------------------------------
Val Schmidt
CCOM/JHC
University of New Hampshire
Chase Ocean Engineering Lab
24 Colovos Road
Durham, NH 03824
e: vschmidt [AT] ccom.unh.edu
m: 614.286.3726



From pje at telecommunity.com  Mon Nov 24 18:57:10 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 24 Nov 2008 12:57:10 -0500
Subject: [Distutils] Using setuptools
In-Reply-To: <E9C41DF1-A285-442F-AE6A-BA608F316C41@ccom.unh.edu>
References: <E9C41DF1-A285-442F-AE6A-BA608F316C41@ccom.unh.edu>
Message-ID: <20081124175541.CE6AC3A405E@sparrow.telecommunity.com>

At 11:55 AM 11/24/2008 -0500, Val Schmidt wrote:
>Hi,
>
>1) When running 'setup.py bdist_egg' the subdirectories build/ and
>dists/ are created. Do people typically add and mange these
>directories and their contents within subversion as well? Or do you
>typically have a separate place, outside of your subversion sandbox
>for building distributions?

It's usually a good idea to exclude those subdirectories using the 
svn:ignore property.


>2) I'm using epydoc to generate documentation for my module. Is it
>appropriate to include the resulting html/ directory and it's contents
>in the egg in some way and if so, how?

No; that should usually be only included in your source distribution, 
unless the package itself (or something it plugs into) will use the 
documentation at runtime.  (For example, a Zope "product" or a Trac 
plugin that need to include HTML help to be displayed when using the 
product or plugin.)


From sienkiew at stsci.edu  Mon Nov 24 23:46:54 2008
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Mon, 24 Nov 2008 17:46:54 -0500
Subject: [Distutils] patch: solving the two major things that people
 dislike about setuptools, part 1
In-Reply-To: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
Message-ID: <492B2EDE.8010800@stsci.edu>

zooko wrote:
> Folks:
>
> There are two things that cause a lot of people to object to the use
> of setuptools: that it changes the semantics of PYTHONPATH, making it
> impossible to override packages on the command-line, and that it
> doesn't work when you run "setup.py install --prefix=./some_dir".

This is #1 on my list of why I hate setuptools.  I actually had it 
installed (we were wondering if we should distribute our software with 
setuptools), but I removed it when I found out that it broke PYTHONPATH.

I have a question about this patch, though:

It is somewhat awkward to apply your patch because setuptools is 
distributed and installed as a .egg file.  Rather than trying to figure 
out how to apply a patch inside a .egg file, I tried to see what the 
effect on easy_install.pth would be.  I changed my easy_install.pth file 
to look like this:

import sys; sys.__plen = len(sys.path)
import sys; print "egg insert at",sys.__egginsert
./nose-0.10.4-py2.5.egg
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; 
p=getattr(sys,'__egginsert',len(os.environ.get('PYTHONPATH','').split(os.pathsep))); 
sys.path[p:p]=new; sys.__egginsert = p+len(new)


I think that this is what your patch would do, except for the debugging.

In my testing, I found that this easy_install.pth file behaves exactly 
the same as the old one.  That is because sys.__egginsert exists and is 
always 0; the value you get from looking at the environment is never 
used.  You can verify this from the print statement I included in the 
.pth file:

[banana:~] sienkiew% python
egg insert at 0
Python 2.5.1 (r251:54863, Mar 18 2008, 11:29:59)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import setuptools ; setuptools.__version__
'0.6c9'


Have I understood your patch correctly?  Do you have different behaviour 
on your system?

I think the correct behaviour is to insert the .egg file either just 
before or just after the directory where we found the .pth file.

So, instead of
p=getattr(sys,'__egginsert',len(os.environ.get('PYTHONPATH','').split(os.pathsep))); 


we want
p=sys.path.index(sitedir);

We can eliminate __egginsert from the code entirely.  As far as I can 
tell, the *only* purpose of __egginsert is to permit the incorrect 
behaviour that your patch is intended to fix.

Does that make sense to you?

Mark S.


From pje at telecommunity.com  Tue Nov 25 01:20:11 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 24 Nov 2008 19:20:11 -0500
Subject: [Distutils] patch: solving the two major things that people
 dislike about setuptools, part 1
In-Reply-To: <492B2EDE.8010800@stsci.edu>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
	<492B2EDE.8010800@stsci.edu>
Message-ID: <20081125001846.9A9303A411C@sparrow.telecommunity.com>

At 05:46 PM 11/24/2008 -0500, Mark Sienkiewicz wrote:
>As far as I can tell, the *only* purpose of __egginsert is to permit 
>the incorrect behaviour that your patch is intended to fix.

The behavior isn't incorrect; it's by design.  If you don't want that 
behavior, just install everything using "-m" (aka 
--multi-version).  The eggs will then not be listed in .pth files, 
but any scripts installed by setuptools (including those installed 
via "setup.py develop") will still load the correct eggs at runtime.

For code not built with setuptools, you'll need to use 
pkg_resources.require() to add the eggs to sys.path dynamically.

Please note that I've rejected Zooko's patch, because it makes it 
impossible to ensure that an easy_install-ed package takes precedence 
over an existing, distutils-installed version of the same package in 
the same PYTHONPATH directory.  This is the intended default behavior 
of easy_install; if you wish to override it, you should use 
--multi-version, and explicitly select the egg(s) to be added to 
sys.path instead. 


From tjk1 at rice.edu  Tue Nov 25 01:47:42 2008
From: tjk1 at rice.edu (tjk1 at rice.edu)
Date: Mon, 24 Nov 2008 18:47:42 -0600
Subject: [Distutils] Error using easy_install
Message-ID: <20081124184742.188967pocan69mcc@webmail.mail.rice.edu>

Hello,

I am trying to install easy_install and setuptools so I can install PyOpenGL.

I am using Windows XP Pro SP 2. I use Python 2.4.3 in the C:\Python24  
directory.

I downloaded and installed setuptools-0.6c9.win32-py2.4.exe without errors.

I have added C:\Python24\Scripts to my Path.

I have installed ctypes, numpy, PIL, SimpleParse, PyGame, and win32all.

When I try to use easy_install I get this error from pkg_resources.py,  
line 1913:

ImportError: No module named command.easy_install

I have read this trouble-shooting advice:
"If EasyInstall/setuptools appears to install correctly, and you can  
run the easy_install command but it fails with an ImportError, the  
most likely cause is that you installed to a location other than  
site-packages, without taking any of the steps described in the Custom  
Installation Locations section below. Please see that section and  
follow the steps to make sure that your custom location will work  
correctly. Then re-install."

But I am not installing to a custom location that I am aware of.  
setuptools is found in my C:\Python24\lib\site-packages\ directory.

I can't find any other information on the web other than the  
troubleshooting advice on Peak (quoted above).

Can someone help me fix my setuptools?

-Tim

From pje at telecommunity.com  Tue Nov 25 02:21:53 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon, 24 Nov 2008 20:21:53 -0500
Subject: [Distutils] Error using easy_install
In-Reply-To: <20081124184742.188967pocan69mcc@webmail.mail.rice.edu>
References: <20081124184742.188967pocan69mcc@webmail.mail.rice.edu>
Message-ID: <20081125012022.EB7893A405E@sparrow.telecommunity.com>

At 06:47 PM 11/24/2008 -0600, tjk1 at rice.edu wrote:
>Hello,
>
>I am trying to install easy_install and setuptools so I can install PyOpenGL.
>
>I am using Windows XP Pro SP 2. I use Python 2.4.3 in the C:\Python24
>directory.
>
>I downloaded and installed setuptools-0.6c9.win32-py2.4.exe without errors.
>
>I have added C:\Python24\Scripts to my Path.
>
>I have installed ctypes, numpy, PIL, SimpleParse, PyGame, and win32all.
>
>When I try to use easy_install I get this error from pkg_resources.py,
>line 1913:
>
>ImportError: No module named command.easy_install
>
>I have read this trouble-shooting advice:
>"If EasyInstall/setuptools appears to install correctly, and you can
>run the easy_install command but it fails with an ImportError, the
>most likely cause is that you installed to a location other than
>site-packages, without taking any of the steps described in the Custom
>Installation Locations section below. Please see that section and
>follow the steps to make sure that your custom location will work
>correctly. Then re-install."
>
>But I am not installing to a custom location that I am aware of.
>setuptools is found in my C:\Python24\lib\site-packages\ directory.

I would check to make sure that you don't have any other location 
where setuptools is installed, after first uninstalling (using the 
Windows control panel add/remove programs).  Search your system for 
any pkg_resources.py files or setuptools directories after 
uninstalling.  If you find any, be sure to delete them before re-installing.


From gael.varoquaux at normalesup.org  Tue Nov 25 07:39:45 2008
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 25 Nov 2008 07:39:45 +0100
Subject: [Distutils] patch: solving the two major things that
	people	dislike about setuptools, part 1
In-Reply-To: <20081125001846.9A9303A411C@sparrow.telecommunity.com>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
	<492B2EDE.8010800@stsci.edu>
	<20081125001846.9A9303A411C@sparrow.telecommunity.com>
Message-ID: <20081125063945.GC21328@phare.normalesup.org>

On Mon, Nov 24, 2008 at 07:20:11PM -0500, Phillip J. Eby wrote:
> At 05:46 PM 11/24/2008 -0500, Mark Sienkiewicz wrote:
>> As far as I can tell, the *only* purpose of __egginsert is to permit the 
>> incorrect behaviour that your patch is intended to fix.
>
> The behavior isn't incorrect; it's by design.  If you don't want that 
> behavior, just install everything using "-m" (aka --multi-version).  The 
> eggs will then not be listed in .pth files, but any scripts installed by 
> setuptools (including those installed via "setup.py develop") will still 
> load the correct eggs at runtime.
>
> For code not built with setuptools, you'll need to use 
> pkg_resources.require() to add the eggs to sys.path dynamically.

Right, setuptools breaks standard Python behavior of a fundamental
feature without giving a strong warning and forces people to monkey patch
sys.path (which, as we are discussing here, as huge consequences on import
semantics).

No wonder system administrators (and packagers, which work with them)
hate setuptools: it breaks expectation of people, and forces them to
learn advanced and specific details of the Python language, which is
fairly irrelevant to their work. Moreover, not respecting environment
variables is a violation of all Unix good-pratices rules.

> Please note that I've rejected Zooko's patch, because it makes it 
> impossible to ensure that an easy_install-ed package takes precedence over 
> an existing, distutils-installed version of the same package in the same 
> PYTHONPATH directory.  This is the intended default behavior of 
> easy_install; if you wish to override it, you should use --multi-version, 
> and explicitly select the egg(s) to be added to sys.path instead. 

I am not surprised you rejected it. You are not open to any suggestion,
and consider only your usecases from your point of view. You act like if
what setuptools does is by definition right, no matter how much people
dislike these feature, and the bad reputation it has. I have sat and
watched discussions on this mailing list for over a year and concluded
that the project was not in a state of moving forward, and that
discussions happening on this mailing list where a loss of time. I gave
up and unsubscribe. The only thing that made me come back was the
announcement of a fork. That fork did not go anywhere. I think I should
unsubscribe again, because all this mailing list will do is increase my
frustration.

Setuptools could be a very important piece of software for the future
Python. It has some _very_ nice features. Your unwillingness to accept
its limitations and fix the problems people are having is sacrificing its
future.

And yes, I am bitter.

Ga?l

From vschmidt at ccom.unh.edu  Tue Nov 25 13:56:39 2008
From: vschmidt at ccom.unh.edu (Val Schmidt)
Date: Tue, 25 Nov 2008 07:56:39 -0500
Subject: [Distutils] Using setuptools
In-Reply-To: <20081124175541.CE6AC3A405E@sparrow.telecommunity.com>
References: <E9C41DF1-A285-442F-AE6A-BA608F316C41@ccom.unh.edu>
	<20081124175541.CE6AC3A405E@sparrow.telecommunity.com>
Message-ID: <1FC75D8F-3A50-4825-A9ED-21A9E72B566C@ccom.unh.edu>

Thanks!

I also noticed that my SOURCES.txt file contains the contents of  
mymodulepy.egg-info (which got added to my subversion repository when  
I initially added the project directory). I suspect I don't want this  
either.

So does it seem like a reasonable working method to develop in one's  
subversion sandbox, check everything in, then checkout a copy of the  
project somewhere else to build distributions? This might help to make  
sure one doesn't inadvertently get the extra files and directories  
created during the build process into subversion and inadvertently in  
your distribution package.

-Val

On Nov 24, 2008, at 12:57 PM, Phillip J. Eby wrote:

> At 11:55 AM 11/24/2008 -0500, Val Schmidt wrote:
>> Hi,
>>
>> 1) When running 'setup.py bdist_egg' the subdirectories build/ and
>> dists/ are created. Do people typically add and mange these
>> directories and their contents within subversion as well? Or do you
>> typically have a separate place, outside of your subversion sandbox
>> for building distributions?
>
> It's usually a good idea to exclude those subdirectories using the  
> svn:ignore property.
>
>
>> 2) I'm using epydoc to generate documentation for my module. Is it
>> appropriate to include the resulting html/ directory and it's  
>> contents
>> in the egg in some way and if so, how?
>
> No; that should usually be only included in your source  
> distribution, unless the package itself (or something it plugs into)  
> will use the documentation at runtime.  (For example, a Zope  
> "product" or a Trac plugin that need to include HTML help to be  
> displayed when using the product or plugin.)
>

------------------------------------------------------
Val Schmidt
CCOM/JHC
University of New Hampshire
Chase Ocean Engineering Lab
24 Colovos Road
Durham, NH 03824
e: vschmidt [AT] ccom.unh.edu
m: 614.286.3726



From pje at telecommunity.com  Tue Nov 25 14:40:41 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 25 Nov 2008 08:40:41 -0500
Subject: [Distutils] patch: solving the two major things that people
 dislike about setuptools, part 1
In-Reply-To: <20081125063945.GC21328@phare.normalesup.org>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
	<492B2EDE.8010800@stsci.edu>
	<20081125001846.9A9303A411C@sparrow.telecommunity.com>
	<20081125063945.GC21328@phare.normalesup.org>
Message-ID: <20081125133912.5C0513A405E@sparrow.telecommunity.com>

At 07:39 AM 11/25/2008 +0100, Gael Varoquaux wrote:
>I am not surprised you rejected it. You are not open to any suggestion,
>and consider only your usecases from your point of view.

On the contrary; it's users who *don't* control their systems whose 
usecase this particular feature supports.  It has no personal value 
to me whatsoever.

Until this feature was added to setuptools, the most frequent bug 
report for easy_install was, "I installed foobar 1.2 with 
easy_install but I'm still importing foobar 1.1...  this program sucks."

Personally, I'm just as bitter about people who insist on thinking 
that their use cases are the only ones that exist, and seem to 
wilfully ignore my repeated explanations of what groups of people 
will be hurt by their "fixes".


From pje at telecommunity.com  Tue Nov 25 14:48:29 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 25 Nov 2008 08:48:29 -0500
Subject: [Distutils] Using setuptools
In-Reply-To: <1FC75D8F-3A50-4825-A9ED-21A9E72B566C@ccom.unh.edu>
References: <E9C41DF1-A285-442F-AE6A-BA608F316C41@ccom.unh.edu>
	<20081124175541.CE6AC3A405E@sparrow.telecommunity.com>
	<1FC75D8F-3A50-4825-A9ED-21A9E72B566C@ccom.unh.edu>
Message-ID: <20081125134658.4598F3A4108@sparrow.telecommunity.com>

At 07:56 AM 11/25/2008 -0500, Val Schmidt wrote:
>Thanks!
>
>I also noticed that my SOURCES.txt file contains the contents of
>mymodulepy.egg-info (which got added to my subversion repository when
>I initially added the project directory). I suspect I don't want this
>either.

That depends on the project; in some cases, files are put manually 
into .egg-info, or there are reasons to keep the generated files 
under revision control.  The .egg-info directory is also 
automatically included in source distribution files.


>So does it seem like a reasonable working method to develop in one's
>subversion sandbox, check everything in, then checkout a copy of the
>project somewhere else to build distributions? This might help to make
>sure one doesn't inadvertently get the extra files and directories
>created during the build process into subversion and inadvertently in
>your distribution package.

I'm not clear on how you can accidentally get something into 
subversion.  In years of developing multiple packages with setuptools 
and subversion, I can't recall that I've ever accidentally typed "svn 
add build" or "svn add foobar.egg-info".  ;-)

Of course, when I start a new project, I start by svn add-ing the 
new, empty directory, and then explicitly add files as I go.  And 
when I start getting annoyed by svn stat showing a bunch of "?"'s, I 
go ahead and set svn:ignore as needed.

It's a lot less work than what you're describing, and even if I go 
too far with a wildcard add, there's always "svn rm" before 
checkin.  (I always svn diff before checkin, so it's hard for an 
accidental add to go unnoticed.)


From david at ar.media.kyoto-u.ac.jp  Tue Nov 25 14:33:47 2008
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Tue, 25 Nov 2008 22:33:47 +0900
Subject: [Distutils] patch: solving the two major things that people
 dislike about setuptools, part 1
In-Reply-To: <20081125133912.5C0513A405E@sparrow.telecommunity.com>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>	<492B2EDE.8010800@stsci.edu>	<20081125001846.9A9303A411C@sparrow.telecommunity.com>	<20081125063945.GC21328@phare.normalesup.org>
	<20081125133912.5C0513A405E@sparrow.telecommunity.com>
Message-ID: <492BFEBB.7090303@ar.media.kyoto-u.ac.jp>

Phillip J. Eby wrote:
> Personally, I'm just as bitter about people who insist on thinking
> that their use cases are the only ones that exist, and seem to
> wilfully ignore my repeated explanations of what groups of people will
> be hurt by their "fixes".

It has nothing to do with what group of people are hurt; setuptools
breaks standard behavior of python. If every developer took the same
approach, and decided to "fix" their bug reports by breaking the general
system behavior, I am sure you would be annoyed by it too.

David

From pje at telecommunity.com  Tue Nov 25 15:24:42 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 25 Nov 2008 09:24:42 -0500
Subject: [Distutils] patch: solving the two major things that people
 dislike about setuptools, part 1
In-Reply-To: <492BFEBB.7090303@ar.media.kyoto-u.ac.jp>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
	<492B2EDE.8010800@stsci.edu>
	<20081125001846.9A9303A411C@sparrow.telecommunity.com>
	<20081125063945.GC21328@phare.normalesup.org>
	<20081125133912.5C0513A405E@sparrow.telecommunity.com>
	<492BFEBB.7090303@ar.media.kyoto-u.ac.jp>
Message-ID: <20081125142311.A963B3A4108@sparrow.telecommunity.com>

At 10:33 PM 11/25/2008 +0900, David Cournapeau wrote:
>Phillip J. Eby wrote:
> > Personally, I'm just as bitter about people who insist on thinking
> > that their use cases are the only ones that exist, and seem to
> > wilfully ignore my repeated explanations of what groups of people will
> > be hurt by their "fixes".
>
>It has nothing to do with what group of people are hurt; setuptools
>breaks standard behavior of python. If every developer took the same
>approach, and decided to "fix" their bug reports by breaking the general
>system behavior, I am sure you would be annoyed by it too.

My point is that people offering "fixes" for setuptools need to take 
into account those other use cases, or else the improvement for one 
group comes at the expense of another.

For example, in this case, if someone wanted to offer a patch that 
changed the behavior in such a way that the added eggs came directly 
before the sys.path directory in which they were contained, but not 
pushed all the way to the beginning of sys.path, that would be an 
acceptable way to change the behavior.

Alternatively, if someone wanted to come up with a more sophisticated 
conflict resolution method for handling non-setuptools-installed 
packages, that might work also.

There indeed might be a great many ways to resolve the issue -- but 
nobody's proposing anything except breaking someone else's use cases 
for their personal convenience.

And I say "personal convenience", because easy_install *does* provide 
an option to not mess with sys.path.  If you use --multi-version to 
install your eggs, easy_install will NOT affect sys.path in ANY 
way.  So it's not like there isn't already a way for easy_install to 
be "pure" here.


From sienkiew at stsci.edu  Tue Nov 25 16:56:33 2008
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Tue, 25 Nov 2008 10:56:33 -0500
Subject: [Distutils] patch: solving the two major things that people
 dislike about setuptools, part 1
In-Reply-To: <20081125001846.9A9303A411C@sparrow.telecommunity.com>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
	<492B2EDE.8010800@stsci.edu>
	<20081125001846.9A9303A411C@sparrow.telecommunity.com>
Message-ID: <492C2031.4020904@stsci.edu>

Phillip J. Eby wrote:
> At 05:46 PM 11/24/2008 -0500, Mark Sienkiewicz wrote:
>> As far as I can tell, the *only* purpose of __egginsert is to permit 
>> the incorrect behaviour that your patch is intended to fix.
>
> The behavior isn't incorrect; it's by design. 

Here is my reasoning for saying it is broken:

[banana:~] sienkiew% which python
/usr/stsci/pyssg/Python-2.5.1/bin/python
[banana:~] sienkiew% ls -l ~/py/lib/python
total 8
drwxr-xr-x   38 sienkiew  ststaff  1292 Nov 25 10:07 nose
-rw-r--r--    1 sienkiew  ststaff  2102 Nov 25 10:07 
nose-0.10.4-py2.5.egg-info
[banana:~] sienkiew% ls -l  
/usr/stsci/pyssg/Python-2.5.1/lib/python2.5/site-packages/
total 680
...unrelated files here...
-rw-r--r--    1 iraf  sienkiew     238 Nov 25 10:06 easy-install.pth
drwxr-xr-x    5 iraf  sienkiew     170 Nov 25 10:06 nose-0.10.0-py2.5.egg
-rwxr-xr-x    1 iraf  sienkiew  328025 Oct  7 14:57 
setuptools-0.6c9-py2.5.egg
-rw-r--r--    1 iraf  sienkiew      29 Nov 25 10:06 setuptools.pth
[banana:~] sienkiew% setenv PYTHONPATH ~/py/lib/python
[banana:~] sienkiew% python
Python 2.5.1 (r251:54863, Mar 18 2008, 11:29:59)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import nose
 >>> nose.__version__
'0.10.0'
 >>> nose.__file__
'/usr/stsci/pyssg/Python-2.5.1/lib/python2.5/site-packages/nose-0.10.0-py2.5.egg/nose/__init__.pyc'


Look what happened:  When I imported "nose",  it chose the nose from the 
system site-packages directory, even though I have a different version 
that occurs earlier on PYTHONPATH.

At this time, I would like to draw your attention to 
http://www.python.org/doc/2.5.2/tut/node8.html section 6.1.2, where it 
describes PYTHONPATH.  "When PYTHONPATH is not set, or when the file is 
not found there, the search continues in an installation-dependent 
default path".   That does not appear to be what happened here.  It 
should have found the module that was on PYTHONPATH, not the module that 
is in the system site-packages.

Please explain why you consider this to be the desired behaviour.


In a later message, you said:

 >For example, in this case, if someone wanted to offer a patch that 
changed the behavior in such a way that the added eggs came directly 
before the sys.path directory in which they were contained, but not 
pushed all the way to the beginning of sys.path, that would be an 
acceptable way to change the behavior.


In my comments on zooko's patch:

 >I think the correct behaviour is to insert the .egg file either just 
before or just after the directory where we found the .pth file.
 >
 >So, instead of
 >p=getattr(sys,'__egginsert',len(os.environ.get('PYTHONPATH','').split(os.pathsep))); 

 >
 >we want
 >p=sys.path.index(sitedir);
 >

Does this meet your criterion without breaking anything else?

IMHO, this is actually not a great patch because it depends on knowledge 
that should be private to distutils, but setuptools is already violating 
that information hiding.  (For example, it assumes that it is safe to 
alter sys.path while distutils is loading the .pth file; I didn't see 
that documented anywhere, but we can see that it works.)

b.t.w. You could make easy_install.pth read:

    import setuptools; setuptools.prep_sys_path()
    module-name.egg
    import setuptools; setuptools.alter_sys_path()

and then patches to the first/last line would be easier -- they would 
just happen when you install a new setuptools.

Mark S.


From tseaver at palladion.com  Tue Nov 25 17:54:52 2008
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 25 Nov 2008 11:54:52 -0500
Subject: [Distutils] Using setuptools
In-Reply-To: <20081125134658.4598F3A4108@sparrow.telecommunity.com>
References: <E9C41DF1-A285-442F-AE6A-BA608F316C41@ccom.unh.edu>	<20081124175541.CE6AC3A405E@sparrow.telecommunity.com>	<1FC75D8F-3A50-4825-A9ED-21A9E72B566C@ccom.unh.edu>
	<20081125134658.4598F3A4108@sparrow.telecommunity.com>
Message-ID: <492C2DDC.7020704@palladion.com>

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

Phillip J. Eby wrote:
> At 07:56 AM 11/25/2008 -0500, Val Schmidt wrote:
>> Thanks!
>>
>> I also noticed that my SOURCES.txt file contains the contents of
>> mymodulepy.egg-info (which got added to my subversion repository when
>> I initially added the project directory). I suspect I don't want this
>> either.
> 
> That depends on the project; in some cases, files are put manually 
> into .egg-info, or there are reasons to keep the generated files 
> under revision control.  The .egg-info directory is also 
> automatically included in source distribution files.
> 
> 
>> So does it seem like a reasonable working method to develop in one's
>> subversion sandbox, check everything in, then checkout a copy of the
>> project somewhere else to build distributions? This might help to make
>> sure one doesn't inadvertently get the extra files and directories
>> created during the build process into subversion and inadvertently in
>> your distribution package.
> 
> I'm not clear on how you can accidentally get something into 
> subversion.  In years of developing multiple packages with setuptools 
> and subversion, I can't recall that I've ever accidentally typed "svn 
> add build" or "svn add foobar.egg-info".  ;-)
> 
> Of course, when I start a new project, I start by svn add-ing the 
> new, empty directory, and then explicitly add files as I go.  And 
> when I start getting annoyed by svn stat showing a bunch of "?"'s, I 
> go ahead and set svn:ignore as needed.
> 
> It's a lot less work than what you're describing, and even if I go 
> too far with a wildcard add, there's always "svn rm" before 
> checkin.  (I always svn diff before checkin, so it's hard for an 
> accidental add to go unnoticed.)

The usual way I get such stuff into SVN is via 'svn import':  I then
have to 'svn rm' it (usually after seeing the checkin message).


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

iD8DBQFJLC3c+gerLs4ltQ4RAng/AKCt1OTqM146bGsmGieljDfgCN5ZIQCePbGE
s5H3JsxqbPdigXk9zq5rivI=
=fztv
-----END PGP SIGNATURE-----


From jan.matejek at novell.com  Tue Nov 25 19:34:24 2008
From: jan.matejek at novell.com (Jan Matejek)
Date: Tue, 25 Nov 2008 19:34:24 +0100
Subject: [Distutils] broken messages from the mailing list
Message-ID: <492C4530.3010500@novell.com>

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

Is it just me, or are the messages that come in lately broken right in
the middle of headers? there's a stray "\n" and it appears that a part
of the following line is missing too. Because of that, my mail client
considers the rest of headers part of the message, and e.g. won't show
the subject.

None of the other lists i'm following do this, so i would think that the
fault is not on my side ... but who knows.

thanks for hints and sorry for the off-topic
m.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkksRTAACgkQjBrWA+AvBr+x1ACfZiTXBPB5GSWbK2d9TQm3EE7e
Tr0AoJLa7uVGw1cYdAi8dl55l/eflVC0
=n+fw
-----END PGP SIGNATURE-----

From marius at pov.lt  Tue Nov 25 20:04:16 2008
From: marius at pov.lt (Marius Gedminas)
Date: Tue, 25 Nov 2008 21:04:16 +0200
Subject: [Distutils] broken messages from the mailing list
In-Reply-To: <492C4530.3010500@novell.com>
References: <492C4530.3010500@novell.com>
Message-ID: <20081125190416.GD7240@fridge.pov.lt>

On Tue, Nov 25, 2008 at 07:34:24PM +0100, Jan Matejek wrote:
> Is it just me, or are the messages that come in lately broken right in
> the middle of headers? there's a stray "\n" and it appears that a part
> of the following line is missing too. Because of that, my mail client
> considers the rest of headers part of the message, and e.g. won't show
> the subject.
> 
> None of the other lists i'm following do this, so i would think that the
> fault is not on my side ... but who knows.

It's just you.

Marius Gedminas
-- 
Cheap, Fast, Good -- pick two.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081125/ee493633/attachment.pgp>

From pje at telecommunity.com  Tue Nov 25 20:39:48 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 25 Nov 2008 14:39:48 -0500
Subject: [Distutils] patch: solving the two major things that people
 dislike about setuptools, part 1
In-Reply-To: <492C2031.4020904@stsci.edu>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
	<492B2EDE.8010800@stsci.edu>
	<20081125001846.9A9303A411C@sparrow.telecommunity.com>
	<492C2031.4020904@stsci.edu>
Message-ID: <20081125193817.7FAD13A405E@sparrow.telecommunity.com>

At 10:56 AM 11/25/2008 -0500, Mark Sienkiewicz wrote:

> >I think the correct behaviour is to insert the .egg file either 
> just before or just after the directory where we found the .pth file.
> >
> >So, instead of
> >p=getattr(sys,'__egginsert',len(os.environ.get('PYTHONPATH','').spl 
> it(os.pathsep)));
> >
> >we want
> >p=sys.path.index(sitedir);
> >
>
>Does this meet your criterion without breaking anything else?

The principle is correct; I'm not sure the implementation is.  For 
case-insensitive filesystems, sitedir may or may not be normalized, 
and sys.path probably isn't.  But yes, that's the general idea.

The only reason I didn't take that approach myself is because my head 
hurt trying to come up with a provably-correct way to implement this 
policy.  ;-)


>IMHO, this is actually not a great patch because it depends on 
>knowledge that should be private to distutils, but setuptools is 
>already violating that information hiding.  (For example, it assumes 
>that it is safe to alter sys.path while distutils is loading the 
>.pth file; I didn't see that documented anywhere, but we can see 
>that it works.)
>
>b.t.w. You could make easy_install.pth read:
>
>    import setuptools; setuptools.prep_sys_path()
>    module-name.egg
>    import setuptools; setuptools.alter_sys_path()
>
>and then patches to the first/last line would be easier -- they 
>would just happen when you install a new setuptools.

It would have to be a separate module, added just for this 
purpose...  and of course it would introduce a runtime dependency 
that would otherwise be unnecessary.


From zooko at zooko.com  Tue Nov 25 21:29:09 2008
From: zooko at zooko.com (zooko)
Date: Tue, 25 Nov 2008 13:29:09 -0700
Subject: [Distutils] patch: solving the two major things that people
	dislike about setuptools, part 1
In-Reply-To: <492B2EDE.8010800@stsci.edu>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
	<492B2EDE.8010800@stsci.edu>
Message-ID: <48D28120-20F1-4CB3-8FF1-12A4352799AB@zooko.com>

On Nov 24, 2008, at 15:46 PM, Mark Sienkiewicz wrote:
>
> We can eliminate __egginsert from the code entirely.  As far as I  
> can tell, the *only* purpose of __egginsert is to permit the  
> incorrect behaviour that your patch is intended to fix.

There are two separable concerns here:

1.  Should the act of "easy_install foodistribution" cause subsequent  
"python -c 'import foomodule'" to get the new, easy-installed foo,  
instead of the pre-existing, distutils-installed foo which is in the  
system directory?

2.  Should the act of "PYTHONPATH=./my-custom-foo" cause subsequent  
"python -c 'import foomodule'" to get the foo in ./my-custom-foo  
instead of the easy-installed foo?

PJE has already made clear (see references on the ticket that I filed  
or in my earlier mail) that he wants the answer to 1 to be "yes",  
because he is supporting a common use case in which a user doesn't  
know how to uninstall the old foo but wants to use easy_install to  
get a new foo.

(I personally am kind of ambivalent about #1, but I have no users  
asking for it to be different so I'm happy to go along with PJE on  
that.)

Issue #2 is actually the one that so many people hate about  
setuptools, including many of my current and prospective users, and  
apparently included you, Mark Sienkiewicz.

I think it is consistent to answer "yes" to both questions, because  
in each case the user has expressed intent -- by saying "easy_install  
foo", you can legitimately be understood as meaning "...and make the  
one I get over-ride any other ones that might already be here.".   
Likewise by saying "PYTHONPATH=./my-custom-foo", you are certainly  
saying "... and make the one I just named override any others".   
Indeed, the Python docs clearly state that Python will respect that  
statement of yours:

http://www.python.org/doc/2.5.2/inst/search-path.html

which says: "The PYTHONPATH variable can be set to a list of paths  
that will be added to the beginning of sys.path.".

My patch is intended to make the answer to #2 be "yes" from now on,  
while preserving the current behavior of the answer to #1 being "yes".

Regards,

Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $10/month

From sienkiew at stsci.edu  Tue Nov 25 22:55:37 2008
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Tue, 25 Nov 2008 16:55:37 -0500
Subject: [Distutils] patch: solving the two major things that people
 dislike about setuptools, part 1
In-Reply-To: <20081125193817.7FAD13A405E@sparrow.telecommunity.com>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
	<492B2EDE.8010800@stsci.edu>
	<20081125001846.9A9303A411C@sparrow.telecommunity.com>
	<492C2031.4020904@stsci.edu>
	<20081125193817.7FAD13A405E@sparrow.telecommunity.com>
Message-ID: <492C7459.1050406@stsci.edu>

Phillip J. Eby wrote:
> At 10:56 AM 11/25/2008 -0500, Mark Sienkiewicz wrote:
>
>> >I think the correct behaviour is to insert the .egg file either just 
>> before or just after the directory where we found the .pth file.
>> >
>> >So, instead of
>> >p=getattr(sys,'__egginsert',len(os.environ.get('PYTHONPATH','').spl 
>> it(os.pathsep)));
>> >
>> >we want
>> >p=sys.path.index(sitedir);
>> >
>>
>> Does this meet your criterion without breaking anything else?
>
> The principle is correct; I'm not sure the implementation is.  For 
> case-insensitive filesystems, sitedir may or may not be normalized, 
> and sys.path probably isn't.  But yes, that's the general idea.
>
> The only reason I didn't take that approach myself is because my head 
> hurt trying to come up with a provably-correct way to implement this 
> policy.  ;-)

That's a good question about normalized names and case-insensitive 
filesystems, but setuptools needs to deal with this problem, so we need 
an answer.

There appear to be two cases:

1. in the system site.py

I looked around lib/python25/site.py a little.  The name of the 
site-packages directory is created in addsitepackages() then passed to 
addsitedir()  where it is appended to sys.path and then passed to 
addpackage().

Since the value that was appended to sys.path is the same value that was 
passed to addpackage() as parameter sitedir, we know that they will match.


2. in the site.py that setuptools put in the directory where setuptools 
installed something

I think the real interesting part is where it says:

    for item in PYTHONPATH:
        addsitedir(item)

Here, PYTHONPATH was constructed directly from the environment variable, 
not somehow derived from sys.path.  This means that it potentially 
_could_ contain duplicate and un-normalized directory names.  But I see 
that we already have access to the function makepath() from the system 
site.py, so we can say:

    for item in PYTHONPATH:
        p,np = makepath(item)
        addsitedir(np)

If you do that, then you know that the directory names that you are 
passing to addsitedir() have been normalized by exactly the same 
algorithm that normalized them for sys.path.  Therefore we know that we 
can use a string comparison to find a match.


So, you know setuptools way better than I do.  Have  I missed anything?


b.t.w.  If you have a few minutes, could you write a paragraph about why 
each of those two big loops in the setuptools site.py are doing what 
they do?  The first one seems to be trying different ways to find the 
system site.py (why?), but I don't see why you would bother with the 
second one.

>>
>>
>> b.t.w. You could make easy_install.pth read:
>>
>>    import setuptools; setuptools.prep_sys_path()
>>    module-name.egg
>>    import setuptools; setuptools.alter_sys_path()
>>
>> and then patches to the first/last line would be easier -- they would 
>> just happen when you install a new setuptools.
>
> It would have to be a separate module, added just for this purpose...  
> and of course it would introduce a runtime dependency that would 
> otherwise be unnecessary.
>

Is that a problem? 


Mark S.


From pje at telecommunity.com  Tue Nov 25 23:10:35 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 25 Nov 2008 17:10:35 -0500
Subject: [Distutils] patch: solving the two major things that people
 dislike about setuptools, part 1
In-Reply-To: <48D28120-20F1-4CB3-8FF1-12A4352799AB@zooko.com>
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
	<492B2EDE.8010800@stsci.edu>
	<48D28120-20F1-4CB3-8FF1-12A4352799AB@zooko.com>
Message-ID: <20081125220905.1D21D3A405E@sparrow.telecommunity.com>

At 01:29 PM 11/25/2008 -0700, zooko wrote:
>My patch is intended to make the answer to #2 be "yes" from now on,
>while preserving the current behavior of the answer to #1 being "yes".

It doesn't preserve #1 in the case where the directory where the eggs 
are installed is *itself* on the PYTHONPATH, which is why I rejected 
it in its current form.



From ben+python at benfinney.id.au  Wed Nov 26 00:55:43 2008
From: ben+python at benfinney.id.au (Ben Finney)
Date: Wed, 26 Nov 2008 10:55:43 +1100
Subject: [Distutils] patch: solving the two major things that people
	dislike about setuptools, part 1
References: <5AA53D0A-98D4-4AF5-843C-DEE1D37C2D24@zooko.com>
	<492B2EDE.8010800@stsci.edu>
	<48D28120-20F1-4CB3-8FF1-12A4352799AB@zooko.com>
Message-ID: <87od031hts.fsf@benfinney.id.au>

zooko <zooko at zooko.com> writes:

> 1.  Should the act of "easy_install foodistribution" cause subsequent
> "python -c 'import foomodule'" to get the new, easy-installed foo,
> instead of the pre-existing, distutils-installed foo which is in the
> system directory?

By the defined behaviour of PYTHONPATH and sys.path, the answer to
this would be ?that depends on where ?easy_install foodistribution?
installed the distribution?. If ?easy_install? wasn't explicitly
instructed to install somewhere other than the system directory, then
it should behave like distutils in this respect and *replace* the
existing instance in the system directory.

In other words, by default setuptools should be installing
distributions in the same place as distutils. If ?easy_install? has
been configured to put things in a different place, then at import
time the rules of PYTHONPATH and sys.path apply ? and setuptools
should leave those alone so the user has the behaviour promised in the
documentation for PYTHONPATH and sys.path.

> PJE has already made clear (see references on the ticket that I
> filed or in my earlier mail) that he wants the answer to 1 to be
> "yes", because he is supporting a common use case in which a user
> doesn't know how to uninstall the old foo but wants to use
> easy_install to get a new foo.

If the argument is that this ?common use case? involves ignoring,
overriding, or munging the existing PYTHONPATH or sys.path, that's a
bad argument. The way to change that behaviour is *not* to have magic
special behaviour in setuptools; it's to change the way Python works
so this use case is supported, if you can convince the Python team to
do so.

Special cases aren't special enough to break the rules. This smells
very much like a special case, and it's entirely possible to support
it with the existing PYTHONPATH and sys.path behaviour, AFAICT.

-- 
 \     ?It is hard to believe that a man is telling the truth when you |
  `\      know that you would lie if you were in his place.? ?Henry L. |
_o__)                                                          Mencken |
Ben Finney


From lists at zopyx.com  Wed Nov 26 08:22:59 2008
From: lists at zopyx.com (Andreas Jung)
Date: Wed, 26 Nov 2008 08:22:59 +0100
Subject: [Distutils] setuptools/buildout: why only one index server
	configurable
Message-ID: <492CF953.9000705@zopyx.com>

Hi there,

in buildout I can define only one alternative index server using 'index 
= http://pypi.zopyx.com'. Now we are in the situation where we are 
running two internal index servers (one for our own internal packages 
and one PyPI mirror). Is there some reason for this limitation? I assume 
this is a limitation/feature coming from setuptools?

Andreas

-- 
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 T?bingen - Germany
Web: www.zopyx.com - Email: info at zopyx.com - Phone +49 - 7071 - 793376
Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
Gesch?ftsf?hrer/Gesellschafter: ZOPYX Limited, Birmingham, UK
------------------------------------------------------------------------
E-Publishing, Python, Zope & Plone development, Consulting

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081126/f3a66853/attachment.vcf>

From ziade.tarek at gmail.com  Wed Nov 26 08:33:52 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 26 Nov 2008 08:33:52 +0100
Subject: [Distutils] setuptools/buildout: why only one index server
	configurable
In-Reply-To: <492CF953.9000705@zopyx.com>
References: <492CF953.9000705@zopyx.com>
Message-ID: <94bdd2610811252333i1acb603flaf9b507362a798a5@mail.gmail.com>

On Wed, Nov 26, 2008 at 8:22 AM, Andreas Jung <lists at zopyx.com> wrote:
> Hi there,
>
> in buildout I can define only one alternative index server using 'index =
> http://pypi.zopyx.com'. Now we are in the situation where we are running two
> internal index servers (one for our own internal packages and one PyPI
> mirror). Is there some reason for this limitation? I assume this is a
> limitation/feature coming from setuptools?

Yes it is.  That is exactly where setuptools needs to evolve.

For the record: I have asked for that a few months ago, and Jim said
he wanted to  stick with setuptools.

So proposed a patch in setuptools to be able to merge several indexes,
(see http://bugs.python.org/setuptools/issue32)

But it hasn't been reviewed yet.

>
> Andreas
>
> --
> ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 T?bingen - Germany
> Web: www.zopyx.com - Email: info at zopyx.com - Phone +49 - 7071 - 793376
> Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
> Gesch?ftsf?hrer/Gesellschafter: ZOPYX Limited, Birmingham, UK
> ------------------------------------------------------------------------
> E-Publishing, Python, Zope & Plone development, Consulting
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
>



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/

From lists at zopyx.com  Wed Nov 26 08:46:10 2008
From: lists at zopyx.com (Andreas Jung)
Date: Wed, 26 Nov 2008 08:46:10 +0100
Subject: [Distutils] setuptools/buildout: why only one index server
	configurable
In-Reply-To: <94bdd2610811252333i1acb603flaf9b507362a798a5@mail.gmail.com>
References: <492CF953.9000705@zopyx.com>
	<94bdd2610811252333i1acb603flaf9b507362a798a5@mail.gmail.com>
Message-ID: <492CFEC2.3040308@zopyx.com>

On 26.11.2008 8:33 Uhr, Tarek Ziad? wrote:
> On Wed, Nov 26, 2008 at 8:22 AM, Andreas Jung<lists at zopyx.com>  wrote:
>> Hi there,
>>
>> in buildout I can define only one alternative index server using 'index =
>> http://pypi.zopyx.com'. Now we are in the situation where we are running two
>> internal index servers (one for our own internal packages and one PyPI
>> mirror). Is there some reason for this limitation? I assume this is a
>> limitation/feature coming from setuptools?
>
> Yes it is.  That is exactly where setuptools needs to evolve.
>
> For the record: I have asked for that a few months ago, and Jim said
> he wanted to  stick with setuptools.
>
> So proposed a patch in setuptools to be able to merge several indexes,
> (see http://bugs.python.org/setuptools/issue32)
>
> But it hasn't been reviewed yet.

I think this is a very helpful patch. We would appreciate it if the 
patch could make it into the next setuptools release asap.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081126/1765c0c0/attachment.vcf>

From ziade.tarek at gmail.com  Wed Nov 26 09:54:31 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 26 Nov 2008 09:54:31 +0100
Subject: [Distutils] setuptools/buildout: why only one index server
	configurable
In-Reply-To: <492CFEC2.3040308@zopyx.com>
References: <492CF953.9000705@zopyx.com>
	<94bdd2610811252333i1acb603flaf9b507362a798a5@mail.gmail.com>
	<492CFEC2.3040308@zopyx.com>
Message-ID: <94bdd2610811260054t9f46108i9eb2c0bebe3ad2ff@mail.gmail.com>

On Wed, Nov 26, 2008 at 8:46 AM, Andreas Jung <lists at zopyx.com> wrote:
> On 26.11.2008 8:33 Uhr, Tarek Ziad? wrote:
>>
>> On Wed, Nov 26, 2008 at 8:22 AM, Andreas Jung<lists at zopyx.com>  wrote:
>>>
>>> Hi there,
>>>
>>> in buildout I can define only one alternative index server using 'index =
>>> http://pypi.zopyx.com'. Now we are in the situation where we are running
>>> two
>>> internal index servers (one for our own internal packages and one PyPI
>>> mirror). Is there some reason for this limitation? I assume this is a
>>> limitation/feature coming from setuptools?
>>
>> Yes it is.  That is exactly where setuptools needs to evolve.
>>
>> For the record: I have asked for that a few months ago, and Jim said
>> he wanted to  stick with setuptools.
>>
>> So proposed a patch in setuptools to be able to merge several indexes,
>> (see http://bugs.python.org/setuptools/issue32)
>>
>> But it hasn't been reviewed yet.
>
> I think this is a very helpful patch. We would appreciate it if the patch
> could make it into the next setuptools release asap.

I made an assumption to use -i but I don't know if it would be better
to have a new argument for it.
Besides, this index merging thing would be helpful for merging
*different* sources

for mirrors, I think we need something specific : a fail-over
mechanism over a list of mirrors for
a given pypi-like server, with a "nearest mirror picked" feature (see
my blob + pep 374 on python wiki)

Regards
Tarek



>
> Andreas
>



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/

From lists at zopyx.com  Wed Nov 26 10:09:38 2008
From: lists at zopyx.com (Andreas Jung)
Date: Wed, 26 Nov 2008 10:09:38 +0100
Subject: [Distutils] setuptools/buildout: why only one index server
	configurable
In-Reply-To: <94bdd2610811260054t9f46108i9eb2c0bebe3ad2ff@mail.gmail.com>
References: <492CF953.9000705@zopyx.com>	
	<94bdd2610811252333i1acb603flaf9b507362a798a5@mail.gmail.com>	
	<492CFEC2.3040308@zopyx.com>
	<94bdd2610811260054t9f46108i9eb2c0bebe3ad2ff@mail.gmail.com>
Message-ID: <492D1252.5000602@zopyx.com>

On 26.11.2008 9:54 Uhr, Tarek Ziad? wrote:
> On Wed, Nov 26, 2008 at 8:46 AM, Andreas Jung<lists at zopyx.com>  wrote:
>> On 26.11.2008 8:33 Uhr, Tarek Ziad? wrote:
>>> On Wed, Nov 26, 2008 at 8:22 AM, Andreas Jung<lists at zopyx.com>   wrote:
>>>> Hi there,
>>>>
>>>> in buildout I can define only one alternative index server using 'index =
>>>> http://pypi.zopyx.com'. Now we are in the situation where we are running
>>>> two
>>>> internal index servers (one for our own internal packages and one PyPI
>>>> mirror). Is there some reason for this limitation? I assume this is a
>>>> limitation/feature coming from setuptools?
>>> Yes it is.  That is exactly where setuptools needs to evolve.
>>>
>>> For the record: I have asked for that a few months ago, and Jim said
>>> he wanted to  stick with setuptools.
>>>
>>> So proposed a patch in setuptools to be able to merge several indexes,
>>> (see http://bugs.python.org/setuptools/issue32)
>>>
>>> But it hasn't been reviewed yet.
>> I think this is a very helpful patch. We would appreciate it if the patch
>> could make it into the next setuptools release asap.
>
> I made an assumption to use -i but I don't know if it would be better
> to have a new argument for it.
> Besides, this index merging thing would be helpful for merging
> *different* sources

Merging is exactly our problem right now (I can get around with 
generating index pages manually right now...works but not really nice).

Not sure where the problem is with the -i parameter. Either we can allow 
serveral -i options or just use something like:

  -i http://pypi.zopyx.com,http://pypi.foo.com


>
> for mirrors, I think we need something specific : a fail-over
> mechanism over a list of mirrors for
> a given pypi-like server, with a "nearest mirror picked" feature (see
> my blob + pep 374 on python wiki)

Mirror selection is a different subject and not the problem here.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081126/b2a220f1/attachment.vcf>

From ziade.tarek at gmail.com  Wed Nov 26 11:04:20 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 26 Nov 2008 11:04:20 +0100
Subject: [Distutils] setuptools/buildout: why only one index server
	configurable
In-Reply-To: <492D1252.5000602@zopyx.com>
References: <492CF953.9000705@zopyx.com>
	<94bdd2610811252333i1acb603flaf9b507362a798a5@mail.gmail.com>
	<492CFEC2.3040308@zopyx.com>
	<94bdd2610811260054t9f46108i9eb2c0bebe3ad2ff@mail.gmail.com>
	<492D1252.5000602@zopyx.com>
Message-ID: <94bdd2610811260204x3771c3a6w307a175f53cc3fb7@mail.gmail.com>

On Wed, Nov 26, 2008 at 10:09 AM, Andreas Jung <lists at zopyx.com> wrote:
> On 26.11.2008 9:54 Uhr, Tarek Ziad? wrote:
>>
>> On Wed, Nov 26, 2008 at 8:46 AM, Andreas Jung<lists at zopyx.com>  wrote:
>>>
>>> On 26.11.2008 8:33 Uhr, Tarek Ziad? wrote:
>>>>
>>>> On Wed, Nov 26, 2008 at 8:22 AM, Andreas Jung<lists at zopyx.com>   wrote:
>>>>>
>>>>> Hi there,
>>>>>
>>>>> in buildout I can define only one alternative index server using 'index
>>>>> =
>>>>> http://pypi.zopyx.com'. Now we are in the situation where we are
>>>>> running
>>>>> two
>>>>> internal index servers (one for our own internal packages and one PyPI
>>>>> mirror). Is there some reason for this limitation? I assume this is a
>>>>> limitation/feature coming from setuptools?
>>>>
>>>> Yes it is.  That is exactly where setuptools needs to evolve.
>>>>
>>>> For the record: I have asked for that a few months ago, and Jim said
>>>> he wanted to  stick with setuptools.
>>>>
>>>> So proposed a patch in setuptools to be able to merge several indexes,
>>>> (see http://bugs.python.org/setuptools/issue32)
>>>>
>>>> But it hasn't been reviewed yet.
>>>
>>> I think this is a very helpful patch. We would appreciate it if the patch
>>> could make it into the next setuptools release asap.
>>
>> I made an assumption to use -i but I don't know if it would be better
>> to have a new argument for it.
>> Besides, this index merging thing would be helpful for merging
>> *different* sources
>
> Merging is exactly our problem right now (I can get around with generating
> index pages manually right now...works but not really nice).
>
> Not sure where the problem is with the -i parameter. Either we can allow
> serveral -i options or just use something like:
>
>  -i http://pypi.zopyx.com,http://pypi.foo.com

well yes, that is how I implemented it, but I don't know if that is
how Phillip Eby wants it.

>
>
>>
>> for mirrors, I think we need something specific : a fail-over
>> mechanism over a list of mirrors for
>> a given pypi-like server, with a "nearest mirror picked" feature (see
>> my blob + pep 374 on python wiki)
>
> Mirror selection is a different subject and not the problem here.

I am saying that because you don't want to merge a source and a
mirror, so as long
as http://pypi.zopyx.com != http://pypi.foo.com, it is OK.


Cheers

>
> Andreas
>



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/

From lists at zopyx.com  Wed Nov 26 11:08:52 2008
From: lists at zopyx.com (Andreas Jung)
Date: Wed, 26 Nov 2008 11:08:52 +0100
Subject: [Distutils] setuptools/buildout: why only one index server
	configurable
In-Reply-To: <94bdd2610811260204x3771c3a6w307a175f53cc3fb7@mail.gmail.com>
References: <492CF953.9000705@zopyx.com>	
	<94bdd2610811252333i1acb603flaf9b507362a798a5@mail.gmail.com>	
	<492CFEC2.3040308@zopyx.com>	
	<94bdd2610811260054t9f46108i9eb2c0bebe3ad2ff@mail.gmail.com>	
	<492D1252.5000602@zopyx.com>
	<94bdd2610811260204x3771c3a6w307a175f53cc3fb7@mail.gmail.com>
Message-ID: <492D2034.5000401@zopyx.com>

On 26.11.2008 11:04 Uhr, Tarek Ziad? wrote:
> On Wed, Nov 26, 2008 at 10:09 AM, Andreas Jung<lists at zopyx.com>  wrote:
>> On 26.11.2008 9:54 Uhr, Tarek Ziad? wrote:
>>> On Wed, Nov 26, 2008 at 8:46 AM, Andreas Jung<lists at zopyx.com>   wrote:
>>>> On 26.11.2008 8:33 Uhr, Tarek Ziad? wrote:
>>>>> On Wed, Nov 26, 2008 at 8:22 AM, Andreas Jung<lists at zopyx.com>    wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> in buildout I can define only one alternative index server using 'index
>>>>>> =
>>>>>> http://pypi.zopyx.com'. Now we are in the situation where we are
>>>>>> running
>>>>>> two
>>>>>> internal index servers (one for our own internal packages and one PyPI
>>>>>> mirror). Is there some reason for this limitation? I assume this is a
>>>>>> limitation/feature coming from setuptools?
>>>>> Yes it is.  That is exactly where setuptools needs to evolve.
>>>>>
>>>>> For the record: I have asked for that a few months ago, and Jim said
>>>>> he wanted to  stick with setuptools.
>>>>>
>>>>> So proposed a patch in setuptools to be able to merge several indexes,
>>>>> (see http://bugs.python.org/setuptools/issue32)
>>>>>
>>>>> But it hasn't been reviewed yet.
>>>> I think this is a very helpful patch. We would appreciate it if the patch
>>>> could make it into the next setuptools release asap.
>>> I made an assumption to use -i but I don't know if it would be better
>>> to have a new argument for it.
>>> Besides, this index merging thing would be helpful for merging
>>> *different* sources
>> Merging is exactly our problem right now (I can get around with generating
>> index pages manually right now...works but not really nice).
>>
>> Not sure where the problem is with the -i parameter. Either we can allow
>> serveral -i options or just use something like:
>>
>>   -i http://pypi.zopyx.com,http://pypi.foo.com
>
> well yes, that is how I implemented it, but I don't know if that is
> how Phillip Eby wants it.
>
>>
>>> for mirrors, I think we need something specific : a fail-over
>>> mechanism over a list of mirrors for
>>> a given pypi-like server, with a "nearest mirror picked" feature (see
>>> my blob + pep 374 on python wiki)
>> Mirror selection is a different subject and not the problem here.
>
> I am saying that because you don't want to merge a source and a
> mirror, so as long
> as http://pypi.zopyx.com != http://pypi.foo.com, it is OK.
>


Of course not. As said initially we are running a PyPI mirror and an egg 
server with our private packages that will never end up on PyPI.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081126/3830cac4/attachment.vcf>

From ziade.tarek at gmail.com  Wed Nov 26 11:12:54 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 26 Nov 2008 11:12:54 +0100
Subject: [Distutils] setuptools/buildout: why only one index server
	configurable
In-Reply-To: <492D2034.5000401@zopyx.com>
References: <492CF953.9000705@zopyx.com>
	<94bdd2610811252333i1acb603flaf9b507362a798a5@mail.gmail.com>
	<492CFEC2.3040308@zopyx.com>
	<94bdd2610811260054t9f46108i9eb2c0bebe3ad2ff@mail.gmail.com>
	<492D1252.5000602@zopyx.com>
	<94bdd2610811260204x3771c3a6w307a175f53cc3fb7@mail.gmail.com>
	<492D2034.5000401@zopyx.com>
Message-ID: <94bdd2610811260212v10ada089j9e373b30db77c740@mail.gmail.com>

On Wed, Nov 26, 2008 at 11:08 AM, Andreas Jung <lists at zopyx.com> wrote:
>
> Of course not. As said initially we are running a PyPI mirror and an egg
> server with our private packages that will never end up on PyPI.
>

Ok great, then let's wait for some feedback from Philipp.

Notice that this patch was posted three months ago...

Cheers



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/

From pje at telecommunity.com  Wed Nov 26 18:21:04 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 26 Nov 2008 12:21:04 -0500
Subject: [Distutils] setuptools/buildout: why only one index server
 configurable
In-Reply-To: <94bdd2610811252333i1acb603flaf9b507362a798a5@mail.gmail.co
 m>
References: <492CF953.9000705@zopyx.com>
	<94bdd2610811252333i1acb603flaf9b507362a798a5@mail.gmail.com>
Message-ID: <20081126171933.4483A3A40B2@sparrow.telecommunity.com>

At 08:33 AM 11/26/2008 +0100, Tarek Ziad? wrote:
>On Wed, Nov 26, 2008 at 8:22 AM, Andreas Jung <lists at zopyx.com> wrote:
> > Hi there,
> >
> > in buildout I can define only one alternative index server using 'index =
> > http://pypi.zopyx.com'. Now we are in the situation where we are 
> running two
> > internal index servers (one for our own internal packages and one PyPI
> > mirror). Is there some reason for this limitation? I assume this is a
> > limitation/feature coming from setuptools?
>
>Yes it is.  That is exactly where setuptools needs to evolve.
>
>For the record: I have asked for that a few months ago, and Jim said
>he wanted to  stick with setuptools.
>
>So proposed a patch in setuptools to be able to merge several indexes,
>(see http://bugs.python.org/setuptools/issue32)
>
>But it hasn't been reviewed yet.

Actually, I've reviewed it, I just haven't commented on it 
yet.  There are a few minor issues that I know how they should be 
fixed (e.g. adding an .isindex(url) method instead of hardcoding 
loops everywhere), but there's a bigger picture issue (search order 
among indexes) that I'm not certain about yet, and it interacts with 
some other issues (like option naming, creation signature of 
PackageIndex, etc.)

So, I'm still mulling that part over.


From akitada at gmail.com  Thu Nov 27 00:39:07 2008
From: akitada at gmail.com (Akira Kitada)
Date: Thu, 27 Nov 2008 08:39:07 +0900
Subject: [Distutils] Fwd: distutils doesn't use some compiler options when
	building
In-Reply-To: <90bb445a0811260928u5a6b5c36ib4b6947472d2b2be@mail.gmail.com>
References: <90bb445a0811260928u5a6b5c36ib4b6947472d2b2be@mail.gmail.com>
Message-ID: <90bb445a0811261539m61665df0n14eb60da2d44303d@mail.gmail.com>

I didn't know distutils has its own list.
Forwarding.


---------- Forwarded message ----------
From: Akira Kitada <akitada at gmail.com>
Date: Thu, Nov 27, 2008 at 2:28 AM
Subject: distutils doesn't use some compiler options when building
To: python-dev at python.org


Hi,

I encountered a weird problem using distutils.
Generally, distutils try to use the same compiler options used for
building Python interpreter,
but it looks like some of them are omitted sometimes.

- CPPFLAGS are not retrieved from the config and only ones in env are used.
- OPT is retrieved from the config, but it's only used when env has CFLAGS.

See: http://svn.python.org/view/python/trunk/Lib/distutils/sysconfig.py

"""
def customize_compiler(compiler):
...
   if compiler.compiler_type == "unix":
       (cc, cxx, opt, cflags, ccshared, ldshared, so_ext) = \
           get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS',
                           'CCSHARED', 'LDSHARED', 'SO')

       if 'CC' in os.environ:
           cc = os.environ['CC']
       if 'CXX' in os.environ:
           cxx = os.environ['CXX']
       if 'LDSHARED' in os.environ:
           ldshared = os.environ['LDSHARED']
       if 'CPP' in os.environ:
           cpp = os.environ['CPP']
       else:
           cpp = cc + " -E"           # not always
       if 'LDFLAGS' in os.environ:
           ldshared = ldshared + ' ' + os.environ['LDFLAGS']
       if 'CFLAGS' in os.environ:
           cflags = opt + ' ' + os.environ['CFLAGS']
           ldshared = ldshared + ' ' + os.environ['CFLAGS']
       if 'CPPFLAGS' in os.environ:
           cpp = cpp + ' ' + os.environ['CPPFLAGS']
           cflags = cflags + ' ' + os.environ['CPPFLAGS']
           ldshared = ldshared + ' ' + os.environ['CPPFLAGS']

       cc_cmd = cc + ' ' + cflags
       compiler.set_executables(
           preprocessor=cpp,
           compiler=cc_cmd,
           compiler_so=cc_cmd + ' ' + ccshared,
           compiler_cxx=cxx,
           linker_so=ldshared,
           linker_exe=cc)

       compiler.shared_lib_extension = so_ext
"""

Are these logics are intentional or just a bug?
If this is intentional behavior, why is that being this way?

Thanks,

From chris at simplistix.co.uk  Thu Nov 27 13:32:58 2008
From: chris at simplistix.co.uk (Chris Withers)
Date: Thu, 27 Nov 2008 12:32:58 +0000
Subject: [Distutils] setuptools/buildout: why only one index
	server	configurable
In-Reply-To: <492CF953.9000705@zopyx.com>
References: <492CF953.9000705@zopyx.com>
Message-ID: <492E937A.6090204@simplistix.co.uk>

Andreas Jung wrote:
> in buildout I can define only one alternative index server using 'index 
> = http://pypi.zopyx.com'. Now we are in the situation where we are 
> running two internal index servers (one for our own internal packages 
> and one PyPI mirror). Is there some reason for this limitation? I assume 
> this is a limitation/feature coming from setuptools?

Is there some reason adding find-links with your other indexes in 
doesn't work? It works for me in the same situation...

Chris

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

From lists at zopyx.com  Thu Nov 27 13:35:43 2008
From: lists at zopyx.com (Andreas Jung)
Date: Thu, 27 Nov 2008 13:35:43 +0100
Subject: [Distutils] setuptools/buildout: why only one index
	server	configurable
In-Reply-To: <492E937A.6090204@simplistix.co.uk>
References: <492CF953.9000705@zopyx.com> <492E937A.6090204@simplistix.co.uk>
Message-ID: <492E941F.7010505@zopyx.com>

On 27.11.2008 13:32 Uhr, Chris Withers wrote:
> Andreas Jung wrote:
>> in buildout I can define only one alternative index server using
>> 'index = http://pypi.zopyx.com'. Now we are in the situation where we
>> are running two internal index servers (one for our own internal
>> packages and one PyPI mirror). Is there some reason for this
>> limitation? I assume this is a limitation/feature coming from setuptools?
>
> Is there some reason adding find-links with your other indexes in
> doesn't work? It works for me in the same situation...

The index package for a complete PyPI mirror is pretty long (too long to 
be loaded and to be parsed). In addition we would have to update the 
index page for our internal egg server upon every change. We do that 
right now but it sux. Using 'index' is appearently much cleaner and 
resource-friendly.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081127/7c17dba2/attachment.vcf>

From m.van.rees at zestsoftware.nl  Thu Nov 27 17:32:54 2008
From: m.van.rees at zestsoftware.nl (Maurits van Rees)
Date: Thu, 27 Nov 2008 16:32:54 +0000 (UTC)
Subject: [Distutils] broken messages from the mailing list
References: <492C4530.3010500@novell.com> <20081125190416.GD7240@fridge.pov.lt>
Message-ID: <ggmi3m$5vm$1@ger.gmane.org>

Marius Gedminas, on 2008-11-25:
> On Tue, Nov 25, 2008 at 07:34:24PM +0100, Jan Matejek wrote:
>> Is it just me, or are the messages that come in lately broken right in
>> the middle of headers? there's a stray "\n" and it appears that a part
>> of the following line is missing too. Because of that, my mail client
>> considers the rest of headers part of the message, and e.g. won't show
>> the subject.
>> 
>> None of the other lists i'm following do this, so i would think that the
>> fault is not on my side ... but who knows.
>
> It's just you.

In my slrn newsreader (reading via gmane) I do sometimes get a warning
that (IIRC) there is a circular reference between some messages.  I am
not sure if I am missing any posts because of that and if this is
related to this post though.  At least I only see that with this list.

Just noting.

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


From Brian.Cameron at Sun.COM  Thu Nov 27 18:21:35 2008
From: Brian.Cameron at Sun.COM (Brian Cameron)
Date: Thu, 27 Nov 2008 11:21:35 -0600
Subject: [Distutils] Are egg files needed when building/installing via
	--root?
Message-ID: <492ED71F.70102@sun.com>


Last October, I sent an email to this list asking how to install modules
which use setuputils so that modules are shipped in a way that is compatible
with Solaris packaging.  It was recommended to me to run "setup.py install"
with the "--root=/foo" argument and this causes the files to be installed
directly to the filesystem and not in an Egg format.

For example, when installing cssutils this way, it installs the python files
to /usr/lib/python2.4/site-packages/cssutils, and not in Egg format.  This
seems to work great, so thanks for the help with that.

However, installing this way seems to also install various egg related files
which I am not sure are actually needed when delivering in this manner.  For
example, installing CSSutils or simplejson puts directories with names like
these on the filesystem:

   /usr/lib/python2.4/site-packages/cssutils-0.9.5.1-py2.4.egg-info
   /usr/lib/python2.4/site-packages/simplejson-2.0.4-py2.4.egg-info

These directories contain files like PKG-INFO, SOURCES.txt,
dependency_links.txt, entry_points.txt, and top_level.txt.

Is there any value in shipping these files when not delivering as Eggs, or
could they safely be just removed?  Should they not be installed when
building with the "--root" option, or is there some other way to disable
having them be installed?

Thanks,

Brian


From nathan at creativecommons.org  Thu Nov 27 21:10:21 2008
From: nathan at creativecommons.org (Nathan Yergler)
Date: Thu, 27 Nov 2008 12:10:21 -0800
Subject: [Distutils] Are egg files needed when building/installing via
	--root?
In-Reply-To: <492ED71F.70102@sun.com>
References: <492ED71F.70102@sun.com>
Message-ID: <c1a864630811271210m39df600ep23abafa721e77ab@mail.gmail.com>

You should probably leave them intact -- they add metadata about the
packages and allow setuptools/easy_install/pkg_resources/etc to use
those installed packages when resolving dependencies.

Nathan

On Thu, Nov 27, 2008 at 9:21 AM, Brian Cameron <Brian.Cameron at sun.com> wrote:
>
> Last October, I sent an email to this list asking how to install modules
> which use setuputils so that modules are shipped in a way that is compatible
> with Solaris packaging.  It was recommended to me to run "setup.py install"
> with the "--root=/foo" argument and this causes the files to be installed
> directly to the filesystem and not in an Egg format.
>
> For example, when installing cssutils this way, it installs the python files
> to /usr/lib/python2.4/site-packages/cssutils, and not in Egg format.  This
> seems to work great, so thanks for the help with that.
>
> However, installing this way seems to also install various egg related files
> which I am not sure are actually needed when delivering in this manner.  For
> example, installing CSSutils or simplejson puts directories with names like
> these on the filesystem:
>
>  /usr/lib/python2.4/site-packages/cssutils-0.9.5.1-py2.4.egg-info
>  /usr/lib/python2.4/site-packages/simplejson-2.0.4-py2.4.egg-info
>
> These directories contain files like PKG-INFO, SOURCES.txt,
> dependency_links.txt, entry_points.txt, and top_level.txt.
>
> Is there any value in shipping these files when not delivering as Eggs, or
> could they safely be just removed?  Should they not be installed when
> building with the "--root" option, or is there some other way to disable
> having them be installed?
>
> Thanks,
>
> Brian
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>

From pje at telecommunity.com  Thu Nov 27 22:00:08 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Thu, 27 Nov 2008 16:00:08 -0500
Subject: [Distutils] Are egg files needed when building/installing via
 --root?
In-Reply-To: <492ED71F.70102@sun.com>
References: <492ED71F.70102@sun.com>
Message-ID: <20081127205838.E52443A40DF@sparrow.telecommunity.com>

At 11:21 AM 11/27/2008 -0600, Brian Cameron wrote:
>Is there any value in shipping these files when not delivering as Eggs, or
>could they safely be just removed?

They cannot safely be removed, for several reasons, including:

1. They identify the installed package so that:
a) code which looks for dependencies at runtime will be satisfied, and
b) easy_install won't install a duplicate of the same package when 
trying to satisfy a dependency

2. Packages which provide or use entry points will not function 
correctly without them

3. Packages which include other metadata or project-specific data 
(such as localizations, translations, etc.) for runtime use will not 
work correctly either.

Thus, neither setuptools nor the distutils provide the option of not 
including .egg-info.


From peter at fry-it.com  Fri Nov 28 16:43:21 2008
From: peter at fry-it.com (Peter Bengtsson)
Date: Fri, 28 Nov 2008 15:43:21 +0000
Subject: [Distutils] Another newbie question regarding setup.py metadata
Message-ID: <bc95c2800811280743h542c17bdr5428b40a90ae1461@mail.gmail.com>

Sorry if this is a stupid question but what I have done wrong to not
get my description and metadata to appear after the upload on
http://pypi.python.org/pypi/slimmer/

The setup.py looks like this::

version = '0.1.27'

setup(name='slimmer',
      version=version,
      description="HTML,XHTML,CSS,JavaScript optimizer",
      long_description="""\
slimmer.py
---------------------

Can slim (X)HTML, CSS and Javascript files to become smaller""",
      keywords='slimmer optimizer optimiser whitespace',
      author='Peter Bengtsson',
      author_email='peter at fry-it.com',
      url='http://www.fry-it.com',
      license='Python',
      classifiers = [
        "Development Status :: 5 - Production/Stable",
        "Environment :: Other Environment",
        "Environment :: Web Environment",
        "Intended Audience :: Developers",
        "License :: OSI Approved :: Python Software Foundation License",
        "Operating System :: OS Independent",
        "Programming Language :: Python",
        "Topic :: Communications",
        "Topic :: Internet :: WWW/HTTP",
        "Topic :: Other/Nonlisted Topic",
        "Topic :: Software Development :: Libraries :: Python Modules",
      ],
      packages=find_packages(exclude=['ez_setup', 'examples', 'tests']),
      include_package_data=True,
      test_suite='slimmer.tests',
      zip_safe=True,
      install_requires=[
          # -*- Extra requirements: -*-
      ],
      entry_points="""
      # -*- Entry points: -*-
      """,
      )


I did upload my little slimmer package to pypi a long time ago but
with a much older distutils that didn't have the test command.
So I've now re-created the package with basic_package and ran setup.py
sdist bdist_egg upload.

-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com

From Brian.Cameron at Sun.COM  Sat Nov 29 06:50:02 2008
From: Brian.Cameron at Sun.COM (Brian Cameron)
Date: Fri, 28 Nov 2008 21:50:02 -0800
Subject: [Distutils] Are egg files needed when building/installing via
 --root?
In-Reply-To: <20081127205838.E52443A40DF@sparrow.telecommunity.com>
References: <492ED71F.70102@sun.com>
	<20081127205838.E52443A40DF@sparrow.telecommunity.com>
Message-ID: <4930D80A.8010205@sun.com>


Phillip:

Thank you and Nathan for the answers.  That is very helpful information
to me.  I have been reading further and took a look at the
documentation, and notice egg files and metadata are described here:

http://peak.telecommunity.com/DevCenter/setuptools#adding-new-egg-info-files
http://peak.telecommunity.com/DevCenter/setuptools#defining-additional-metadata

However, I didn't find any references to the situation I am describing,
about how these files are useful to install even when not shipping the
module as eggs.  If such documentation exists, I am sure that would help
me further understand how this works.  Or might the documentation
benefit from discussing this a bit more?  The documentation does not 
provide any real examples of what constitutes metadata, or why being
able to store metadata is generally useful.

Thanks again,

Brian


> At 11:21 AM 11/27/2008 -0600, Brian Cameron wrote:
>> Is there any value in shipping these files when not delivering as 
>> Eggs, or
>> could they safely be just removed?
> 
> They cannot safely be removed, for several reasons, including:
> 
> 1. They identify the installed package so that:
> a) code which looks for dependencies at runtime will be satisfied, and
> b) easy_install won't install a duplicate of the same package when 
> trying to satisfy a dependency
> 
> 2. Packages which provide or use entry points will not function 
> correctly without them
> 
> 3. Packages which include other metadata or project-specific data (such 
> as localizations, translations, etc.) for runtime use will not work 
> correctly either.
> 
> Thus, neither setuptools nor the distutils provide the option of not 
> including .egg-info.
> 


From pje at telecommunity.com  Sat Nov 29 05:22:23 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 28 Nov 2008 23:22:23 -0500
Subject: [Distutils] Are egg files needed when building/installing via
 --root?
In-Reply-To: <4930D80A.8010205@sun.com>
References: <492ED71F.70102@sun.com>
	<20081127205838.E52443A40DF@sparrow.telecommunity.com>
	<4930D80A.8010205@sun.com>
Message-ID: <20081129042051.87EF43A40B2@sparrow.telecommunity.com>

At 09:50 PM 11/28/2008 -0800, Brian Cameron wrote:
>Phillip:
>
>Thank you and Nathan for the answers.  That is very helpful information
>to me.  I have been reading further and took a look at the
>documentation, and notice egg files and metadata are described here:
>
>http://peak.telecommunity.com/DevCenter/setuptools#adding-new-egg-info-files
>http://peak.telecommunity.com/DevCenter/setuptools#defining-additional-metadata
>
>However, I didn't find any references to the situation I am describing,
>about how these files are useful to install even when not shipping the
>module as eggs.  If such documentation exists, I am sure that would help
>me further understand how this works.  Or might the documentation
>benefit from discussing this a bit more?  The documentation does not 
>provide any real examples of what constitutes metadata, or why being
>able to store metadata is generally useful.

Please feel free to suggest specific additions, especially in the 
form of a patch.  ;-)

If you're looking for documentation of the internal format of eggs, please see:

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

Which describes the contents of .egg-info directories.

I'm making the assumption, by the way, that my response was clear as 
to why you should not remove the .egg-info directories; even if you 
can get away with it for some specific subset of packages and/or 
installation circumstances, you will be bitten eventually when your 
set of packages expands or a package begins using the other features 
at a later date, etc.  This has already happened to at least one 
Linux distribution that I'm aware of; they had been stripping out the 
.egg-info and it then caused more problems for their users than it 
was worth.  (There really wasn't any benefit to stripping them out, 
actually, since the space usage is minimal compared to the size of 
the code in a typical package, especially for the distutils-generated 
.egg-info which is only one short file per package.)


From zooko at zooko.com  Sat Nov 29 14:17:03 2008
From: zooko at zooko.com (zooko)
Date: Sat, 29 Nov 2008 06:17:03 -0700
Subject: [Distutils] Are egg files needed when building/installing via
	--root?
In-Reply-To: <20081129042051.87EF43A40B2@sparrow.telecommunity.com>
References: <492ED71F.70102@sun.com>
	<20081127205838.E52443A40DF@sparrow.telecommunity.com>
	<4930D80A.8010205@sun.com>
	<20081129042051.87EF43A40B2@sparrow.telecommunity.com>
Message-ID: <670161DF-A5DA-439B-89DF-6BBEEE24076B@zooko.com>

On Nov 28, 2008, at 21:22 PM, Phillip J. Eby wrote:

> This has already happened to at least one Linux distribution that  
> I'm aware of; they had been stripping out the .egg-info and it then  
> caused more problems for their users than it was worth.

I'm aware of three linux distributions that used to strip out .egg- 
info files and then changes their policy and now leave them  
unmolested: Fedora, Debian and Ubuntu.

Regards,

Zooko

From Brian.Cameron at Sun.COM  Sat Nov 29 18:39:39 2008
From: Brian.Cameron at Sun.COM (Brian Cameron)
Date: Sat, 29 Nov 2008 09:39:39 -0800
Subject: [Distutils] Are egg files needed when building/installing via
 --root?
In-Reply-To: <670161DF-A5DA-439B-89DF-6BBEEE24076B@zooko.com>
References: <492ED71F.70102@sun.com>
	<20081127205838.E52443A40DF@sparrow.telecommunity.com>
	<4930D80A.8010205@sun.com>
	<20081129042051.87EF43A40B2@sparrow.telecommunity.com>
	<670161DF-A5DA-439B-89DF-6BBEEE24076B@zooko.com>
Message-ID: <49317E5B.4000309@sun.com>


>> This has already happened to at least one Linux distribution that I'm 
>> aware of; they had been stripping out the .egg-info and it then caused 
>> more problems for their users than it was worth.
> 
> I'm aware of three linux distributions that used to strip out .egg-info 
> files and then changes their policy and now leave them unmolested: 
> Fedora, Debian and Ubuntu.

Interesting, what sort of problems did the distros run into if they
removed the files?  That would be the sort of information that would
be useful to add to the manual, I think.

Brian


From tseaver at palladion.com  Sat Nov 29 16:54:37 2008
From: tseaver at palladion.com (Tres Seaver)
Date: Sat, 29 Nov 2008 10:54:37 -0500
Subject: [Distutils] Another newbie question regarding setup.py metadata
In-Reply-To: <bc95c2800811280743h542c17bdr5428b40a90ae1461@mail.gmail.com>
References: <bc95c2800811280743h542c17bdr5428b40a90ae1461@mail.gmail.com>
Message-ID: <493165BD.6050604@palladion.com>

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

Peter Bengtsson wrote:
> Sorry if this is a stupid question but what I have done wrong to not
> get my description and metadata to appear after the upload on
> http://pypi.python.org/pypi/slimmer/
> 
> The setup.py looks like this::
> 
> version = '0.1.27'
> 
> setup(name='slimmer',
>       version=version,
>       description="HTML,XHTML,CSS,JavaScript optimizer",
>       long_description="""\
> slimmer.py
> ---------------------
> 
> Can slim (X)HTML, CSS and Javascript files to become smaller""",
>       keywords='slimmer optimizer optimiser whitespace',
>       author='Peter Bengtsson',
>       author_email='peter at fry-it.com',
>       url='http://www.fry-it.com',
>       license='Python',
>       classifiers = [
>         "Development Status :: 5 - Production/Stable",
>         "Environment :: Other Environment",
>         "Environment :: Web Environment",
>         "Intended Audience :: Developers",
>         "License :: OSI Approved :: Python Software Foundation License",
>         "Operating System :: OS Independent",
>         "Programming Language :: Python",
>         "Topic :: Communications",
>         "Topic :: Internet :: WWW/HTTP",
>         "Topic :: Other/Nonlisted Topic",
>         "Topic :: Software Development :: Libraries :: Python Modules",
>       ],
>       packages=find_packages(exclude=['ez_setup', 'examples', 'tests']),
>       include_package_data=True,
>       test_suite='slimmer.tests',
>       zip_safe=True,
>       install_requires=[
>           # -*- Extra requirements: -*-
>       ],
>       entry_points="""
>       # -*- Entry points: -*-
>       """,
>       )
> 
> 
> I did upload my little slimmer package to pypi a long time ago but
> with a much older distutils that didn't have the test command.
> So I've now re-created the package with basic_package and ran setup.py
> sdist bdist_egg upload.

Try: adding 'register' to the list of commands.


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

iD8DBQFJMWW9+gerLs4ltQ4RAqbEAKDG6uTNRdGjS4TCbHw9wvN2RevYQgCgzqtq
YB9wlWe2je8T/4gGcLz5RMw=
=xdrx
-----END PGP SIGNATURE-----


From peter at fry-it.com  Sat Nov 29 20:42:26 2008
From: peter at fry-it.com (Peter Bengtsson)
Date: Sat, 29 Nov 2008 19:42:26 +0000
Subject: [Distutils] Another newbie question regarding setup.py metadata
In-Reply-To: <493165BD.6050604@palladion.com>
References: <bc95c2800811280743h542c17bdr5428b40a90ae1461@mail.gmail.com>
	<493165BD.6050604@palladion.com>
Message-ID: <bc95c2800811291142v55ad75cbg86e6ac170ab5dcff@mail.gmail.com>

2008/11/29 Tres Seaver <tseaver at palladion.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Peter Bengtsson wrote:
>> Sorry if this is a stupid question but what I have done wrong to not
>> get my description and metadata to appear after the upload on
>> http://pypi.python.org/pypi/slimmer/
>>
>> The setup.py looks like this::
>>
>> version = '0.1.27'
>>
>> setup(name='slimmer',
>>       version=version,
>>       description="HTML,XHTML,CSS,JavaScript optimizer",
>>       long_description="""\
>> slimmer.py
>> ---------------------
>>
>> Can slim (X)HTML, CSS and Javascript files to become smaller""",
>>       keywords='slimmer optimizer optimiser whitespace',
>>       author='Peter Bengtsson',
>>       author_email='peter at fry-it.com',
>>       url='http://www.fry-it.com',
>>       license='Python',
>>       classifiers = [
>>         "Development Status :: 5 - Production/Stable",
>>         "Environment :: Other Environment",
>>         "Environment :: Web Environment",
>>         "Intended Audience :: Developers",
>>         "License :: OSI Approved :: Python Software Foundation License",
>>         "Operating System :: OS Independent",
>>         "Programming Language :: Python",
>>         "Topic :: Communications",
>>         "Topic :: Internet :: WWW/HTTP",
>>         "Topic :: Other/Nonlisted Topic",
>>         "Topic :: Software Development :: Libraries :: Python Modules",
>>       ],
>>       packages=find_packages(exclude=['ez_setup', 'examples', 'tests']),
>>       include_package_data=True,
>>       test_suite='slimmer.tests',
>>       zip_safe=True,
>>       install_requires=[
>>           # -*- Extra requirements: -*-
>>       ],
>>       entry_points="""
>>       # -*- Entry points: -*-
>>       """,
>>       )
>>
>>
>> I did upload my little slimmer package to pypi a long time ago but
>> with a much older distutils that didn't have the test command.
>> So I've now re-created the package with basic_package and ran setup.py
>> sdist bdist_egg upload.
>
> Try: adding 'register' to the list of commands.
>

That did it!!
Thanks

>
> Tres.
> - --
> ===================================================================
> Tres Seaver          +1 540-429-0999          tseaver at palladion.com
> Palladion Software   "Excellence by Design"    http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJMWW9+gerLs4ltQ4RAqbEAKDG6uTNRdGjS4TCbHw9wvN2RevYQgCgzqtq
> YB9wlWe2je8T/4gGcLz5RMw=
> =xdrx
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com

From pje at telecommunity.com  Sat Nov 29 23:51:39 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 29 Nov 2008 17:51:39 -0500
Subject: [Distutils] Are egg files needed when building/installing via
 --root?
In-Reply-To: <49317E5B.4000309@sun.com>
References: <492ED71F.70102@sun.com>
	<20081127205838.E52443A40DF@sparrow.telecommunity.com>
	<4930D80A.8010205@sun.com>
	<20081129042051.87EF43A40B2@sparrow.telecommunity.com>
	<670161DF-A5DA-439B-89DF-6BBEEE24076B@zooko.com>
	<49317E5B.4000309@sun.com>
Message-ID: <20081129225005.E218A3A40B2@sparrow.telecommunity.com>

At 09:39 AM 11/29/2008 -0800, Brian Cameron wrote:

>>>This has already happened to at least one Linux distribution that 
>>>I'm aware of; they had been stripping out the .egg-info and it 
>>>then caused more problems for their users than it was worth.
>>I'm aware of three linux distributions that used to strip out 
>>.egg-info files and then changes their policy and now leave them 
>>unmolested: Fedora, Debian and Ubuntu.
>
>Interesting, what sort of problems did the distros run into if they
>removed the files?  That would be the sort of information that would
>be useful to add to the manual, I think.

Actually, I would tend to assume that randomly removing files from a 
piece of software distribution would be pretty likely to produce 
problems, so I don't get why people try to delete them in the first 
place...  or even why they'd *want* to.

Again, if you'd like to submit a documentation patch at a spot you 
think would be suitable, I'll certainly look it over for 
inclusion.  Personally, I have no idea what to say or where to say 
it, as it sounds too much to me like saying, "we suggest you not 
remove your internal organs, as doing so may cause undesirable results."  ;-)


From ziade.tarek at gmail.com  Sun Nov 30 14:14:58 2008
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 30 Nov 2008 14:14:58 +0100
Subject: [Distutils] setuptools/buildout: why only one index server
	configurable
In-Reply-To: <20081126171933.4483A3A40B2@sparrow.telecommunity.com>
References: <492CF953.9000705@zopyx.com>
	<94bdd2610811252333i1acb603flaf9b507362a798a5@mail.gmail.com>
	<20081126171933.4483A3A40B2@sparrow.telecommunity.com>
Message-ID: <94bdd2610811300514s12f3c411j7d4f80779d23cbf@mail.gmail.com>

On Wed, Nov 26, 2008 at 6:21 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 08:33 AM 11/26/2008 +0100, Tarek Ziad? wrote:
>>
>> On Wed, Nov 26, 2008 at 8:22 AM, Andreas Jung <lists at zopyx.com> wrote:
>> > Hi there,
>> >
>> > in buildout I can define only one alternative index server using 'index
>> > =
>> > http://pypi.zopyx.com'. Now we are in the situation where we are running
>> > two
>> > internal index servers (one for our own internal packages and one PyPI
>> > mirror). Is there some reason for this limitation? I assume this is a
>> > limitation/feature coming from setuptools?
>>
>> Yes it is.  That is exactly where setuptools needs to evolve.
>>
>> For the record: I have asked for that a few months ago, and Jim said
>> he wanted to  stick with setuptools.
>>
>> So proposed a patch in setuptools to be able to merge several indexes,
>> (see http://bugs.python.org/setuptools/issue32)
>>
>> But it hasn't been reviewed yet.
>
> Actually, I've reviewed it, I just haven't commented on it yet.  There are a
> few minor issues that I know how they should be fixed (e.g. adding an
> .isindex(url) method instead of hardcoding loops everywhere), but there's a
> bigger picture issue (search order among indexes) that I'm not certain about
> yet, and it interacts with some other issues (like option naming, creation
> signature of PackageIndex, etc.)
>
> So, I'm still mulling that part over.

Ok great. For the ordering I supposed that the order given in the option could
be the priority: the first index is tried, then the second, etc.




>
>



-- 
Tarek Ziad? | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/

From mmanns at gmx.net  Sun Nov 30 23:03:30 2008
From: mmanns at gmx.net (Martin Manns)
Date: Sun, 30 Nov 2008 22:03:30 +0000 (UTC)
Subject: [Distutils] =?utf-8?q?Help_with_easy=5Finstall?=
Message-ID: <loom.20081130T213635-311@post.gmane.org>

Hi,

I am developing a small pet project that I call pyspread (A small spreadsheet
that accepts Python in cells, further info at: http://pyspread.sf.net).

Now some users complained that it does not install correctly with easy_install
even though distutils work. I tried for some time fixing it, but I was not too
successful. 

The main problem is that the .pth file and the subdirectory are not created on
installation, which works all right with python setup.py install. 

First, I thought that my easy_install installation is broken (I am using Debian
testing with the version in the apt repository). However, after I read a few
posts in this list, I believe that I stumbled into some gotchas that are
definitively not in the main download page manual.

Any idea how I could get the directories set up with easy install?
Is this in a FAQ that I am unaware of?

My setup.py code is posted below. 
You can find the bug report at
http://sourceforge.net/tracker/index.php?func=detail&aid=2036736&group_id=224598&atid=1062244

Thanks in advance

Regards

Martin

--- setup.py ---
#!/usr/bin/env python

from distutils.core import setup
from distutils.sysconfig import get_python_lib

setup(name='pyspread',
      version='0.0.10a',
      description='A spreadsheet that accepts a pure python expression in each
cell.',
      license='GPL v3 :: GNU General Public License',
      classifiers=[ 'Development Status :: 3 - Alpha',
                    'Intended Audience :: End Users/Desktop',
      ],
      author='Martin Manns',
      author_email='mmanns at gmx.net',
      url='http://sourceforge.net/projects/pyspread/',
      requires=['numpy (>=1.1)', 'wx (>=2.7)'],
      scripts=['pyspread/pyspread.py'],
      packages=['pyspread'],
      package_dir={'pyspread': 'pyspread'},
      package_data={'pyspread': ['icons/*.png', 'icons/actions/*.png', \
                         'examples/*', \
                         'doc/manual.html', 'README', 'COPYING']},
)

import distutils.sysconfig
try:
    pthfile = open(get_python_lib() + "/pyspread.pth", 'w')
    pthfile.write("pyspread")
    pthfile.close()
except IOError:
    print 'Creation of ' + distutils.sysconfig.get_python_lib() + ' pyspread.pth
failed.'


From pje at telecommunity.com  Sun Nov 30 23:17:52 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 30 Nov 2008 17:17:52 -0500
Subject: [Distutils] Help with easy_install
In-Reply-To: <loom.20081130T213635-311@post.gmane.org>
References: <loom.20081130T213635-311@post.gmane.org>
Message-ID: <20081130221619.DB5553A407F@sparrow.telecommunity.com>

At 10:03 PM 11/30/2008 +0000, Martin Manns wrote:
>Hi,
>
>I am developing a small pet project that I call pyspread (A small spreadsheet
>that accepts Python in cells, further info at: http://pyspread.sf.net).
>
>Now some users complained that it does not install correctly with easy_install
>even though distutils work. I tried for some time fixing it, but I was not too
>successful.
>
>The main problem is that the .pth file and the subdirectory are not created on
>installation, which works all right with python setup.py install.

 From reading your setup script, I don't understand why your package 
needs a .pth file of its own, let alone why it's writing it directly 
in the setup script.  I would expect it to work correctly if you 
simply delete that portion of the setup script.  In fact, it works 
for me that way.

One other thing you need to change if you want easy_install to handle 
dependencies:

>       requires=['numpy (>=1.1)', 'wx (>=2.7)'],

Either change this line (or add another) saying:

     install_requires=["numpy>=1.1", "wx>=2.7"],

Also note that this line is superfluous (neither distutils nor 
setuptools need it):

>       package_dir={'pyspread': 'pyspread'},


And of course, delete the entire block below; as far as I can tell, 
it's not needed for distutils or setuptools.

>import distutils.sysconfig
>try:
>     pthfile = open(get_python_lib() + "/pyspread.pth", 'w')
>     pthfile.write("pyspread")
>     pthfile.close()
>except IOError:
>     print 'Creation of ' + distutils.sysconfig.get_python_lib() + ' 
> pyspread.pth
>failed.'