From quasipedia at gmail.com  Tue Oct  4 09:51:04 2011
From: quasipedia at gmail.com (Mac Ryan)
Date: Tue, 4 Oct 2011 09:51:04 +0200
Subject: [Distutils] Persistent system-level files across installations
Message-ID: <20111004095104.0cc15692@jabbar>

I am using stdeb to produce my debian packages and I am a novice when
it comes to packaging in general, so bear with me if I am mixing
together apples and oranges and just help me understanding better...

What I am trying to achieve is to have certain files of my application
that are persistent across software updates in other words: updating
from mypackage-1.0 to mypackage-1.0.1 should imply overwriting only
certain files of the v.1.0 if present, but not all of them. These
"persistent files" are application-specific and not user-specific (i.e.
they don't live in the /home/* hierarchy).

[If this information is of any use: said files are sqlite files with
usage statistic]

My questions:

At what level should I manage this? It is something I have to manage
within my application (1), within my setup.py configuration script (2),
or is something I am obliged to handle by dropping stdeb and packaging
for debian "from scratch" (3)? 

Any link to examples very much appreciated!

Thank you in advance for your time! :)

/mac

From flub at devork.be  Tue Oct  4 14:55:18 2011
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 4 Oct 2011 13:55:18 +0100
Subject: [Distutils] Persistent system-level files across installations
In-Reply-To: <20111004095104.0cc15692@jabbar>
References: <20111004095104.0cc15692@jabbar>
Message-ID: <CAAWk_DwhnUjdYxNPo0i4CA+ooCN0ehQ5uur==TE0qViCOpiVJw@mail.gmail.com>

Hi Mac

On 4 October 2011 08:51, Mac Ryan <quasipedia at gmail.com> wrote:
> What I am trying to achieve is to have certain files of my application
> that are persistent across software updates in other words: updating
> from mypackage-1.0 to mypackage-1.0.1 should imply overwriting only
> certain files of the v.1.0 if present, but not all of them. These
> "persistent files" are application-specific and not user-specific (i.e.
> they don't live in the /home/* hierarchy).
>
> [If this information is of any use: said files are sqlite files with
> usage statistic]

Since you're targeting Debian the FHS [0] applies and these files
should go into /var.

> At what level should I manage this? It is something I have to manage
> within my application (1), within my setup.py configuration script (2),
> or is something I am obliged to handle by dropping stdeb and packaging
> for debian "from scratch" (3)?

You will have to do this in your application yourself: don't let a
file be installed but create them at runtime.  If you're following
Debian policy (which you should) you should remove the created files
in the postrm script of the Debian package when the package is being
purged (but not when removed).  The Debian policy [1] explains all
these rules.  As I've never used stdeb I don't know if that provides
you with the required functionality however.


Regards,
Floris


[0] http://www.pathname.com/fhs/
[1] http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From quasipedia at gmail.com  Tue Oct  4 15:20:14 2011
From: quasipedia at gmail.com (Mac Ryan)
Date: Tue, 4 Oct 2011 15:20:14 +0200
Subject: [Distutils] Persistent system-level files across installations
In-Reply-To: <CAAWk_DwhnUjdYxNPo0i4CA+ooCN0ehQ5uur==TE0qViCOpiVJw@mail.gmail.com>
References: <20111004095104.0cc15692@jabbar>
	<CAAWk_DwhnUjdYxNPo0i4CA+ooCN0ehQ5uur==TE0qViCOpiVJw@mail.gmail.com>
Message-ID: <20111004152014.570a08e5@jabbar>

On Tue, 4 Oct 2011 13:55:18 +0100
Floris Bruynooghe <flub at devork.be> wrote:

> Hi Mac
> 
> ...

Thank you Floris for the quick and exhaustive answer! :)

/mac


From barry at python.org  Wed Oct  5 22:50:49 2011
From: barry at python.org (Barry Warsaw)
Date: Wed, 5 Oct 2011 16:50:49 -0400
Subject: [Distutils] Persistent system-level files across installations
In-Reply-To: <CAAWk_DwhnUjdYxNPo0i4CA+ooCN0ehQ5uur==TE0qViCOpiVJw@mail.gmail.com>
References: <20111004095104.0cc15692@jabbar>
	<CAAWk_DwhnUjdYxNPo0i4CA+ooCN0ehQ5uur==TE0qViCOpiVJw@mail.gmail.com>
Message-ID: <20111005165049.4c1172a8@resist.wooz.org>

On Oct 04, 2011, at 01:55 PM, Floris Bruynooghe wrote:

>You will have to do this in your application yourself: don't let a
>file be installed but create them at runtime.  If you're following
>Debian policy (which you should) you should remove the created files
>in the postrm script of the Debian package when the package is being
>purged (but not when removed).  The Debian policy [1] explains all
>these rules.  As I've never used stdeb I don't know if that provides
>you with the required functionality however.

No, I don't believe it does, though it's been a while since I used stdeb.  Not
that it provides any more help for Mac's original question, but these days I
tend to use pkgme for the initial debian layout (if I don't just cargo cult it
from a working package that is ;).

    https://launchpad.net/pkgme

Cheers,
-Barry

From andrea.crotti.0 at gmail.com  Thu Oct  6 12:03:48 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Thu, 06 Oct 2011 11:03:48 +0100
Subject: [Distutils] buildout & develop
Message-ID: <4E8D7D04.4010401@gmail.com>

I am in the current situation, I have an application that uses a lot of 
libraries (ETS / pyqt...).

In plus there for every application there are a lot of eggs, which are 
actually directory eggs.

At the moment we run everything in a brutal way messing up with the 
system, but I thought
that we can change this using
- a pypi server on localhost
- zc.buildout and smarter setup.py files

To run in production mode it looks relatively easy, build the eggs in a 
place
where the pypiserver looks and run everything.

But is it possible to use the equivalent of "setup.py develop"?

Ideally whenever I save a new file it should run the python setup.py 
develop only for that
where it belongs, any idea on how to do something like this?

From benji at benjiyork.com  Thu Oct  6 15:07:26 2011
From: benji at benjiyork.com (Benji York)
Date: Thu, 6 Oct 2011 09:07:26 -0400
Subject: [Distutils] buildout & develop
In-Reply-To: <4E8D7D04.4010401@gmail.com>
References: <4E8D7D04.4010401@gmail.com>
Message-ID: <CAC8tyQ40VfXuaUmCZ2-Fkvzic_8ritEpBpk97LGfhMQbmE9QwQ@mail.gmail.com>

On Thu, Oct 6, 2011 at 6:03 AM, Andrea Crotti <andrea.crotti.0 at gmail.com> wrote:
> I am in the current situation, I have an application that uses a lot of
> libraries (ETS / pyqt...).
>
> In plus there for every application there are a lot of eggs, which are
> actually directory eggs.
>
> At the moment we run everything in a brutal way messing up with the system,
> but I thought
> that we can change this using
> - a pypi server on localhost
> - zc.buildout and smarter setup.py files
>
> To run in production mode it looks relatively easy, build the eggs in a
> place
> where the pypiserver looks and run everything.
>
> But is it possible to use the equivalent of "setup.py develop"?

The "develop" option should do what you want:
http://pypi.python.org/pypi/zc.buildout/1.5.2#work-on-a-package

> Ideally whenever I save a new file it should run the python setup.py develop
> only for that
> where it belongs, any idea on how to do something like this?

I'm afraid I didn't understand your question.

-- 
Benji York

From quasipedia at gmail.com  Thu Oct  6 16:52:15 2011
From: quasipedia at gmail.com (Mac Ryan)
Date: Thu, 6 Oct 2011 16:52:15 +0200
Subject: [Distutils] Persistent system-level files across installations
In-Reply-To: <20111005165049.4c1172a8@resist.wooz.org>
References: <20111004095104.0cc15692@jabbar>
	<CAAWk_DwhnUjdYxNPo0i4CA+ooCN0ehQ5uur==TE0qViCOpiVJw@mail.gmail.com>
	<20111005165049.4c1172a8@resist.wooz.org>
Message-ID: <20111006165215.66a3ac11@jabbar>

On Wed, 5 Oct 2011 16:50:49 -0400
Barry Warsaw <barry at python.org> wrote:

> No, I don't believe it does, though it's been a while since I used
> stdeb.  Not that it provides any more help for Mac's original
> question, but these days I tend to use pkgme for the initial debian
> layout (if I don't just cargo cult it from a working package that
> is ;).
> 
>     https://launchpad.net/pkgme

I heard about it before but I never tried it myself. I will have a look
at it then. Thanks for the tip!

/mac

From reinout at vanrees.org  Thu Oct  6 17:43:43 2011
From: reinout at vanrees.org (Reinout van Rees)
Date: Thu, 06 Oct 2011 17:43:43 +0200
Subject: [Distutils] buildout & develop
In-Reply-To: <4E8D7D04.4010401@gmail.com>
References: <4E8D7D04.4010401@gmail.com>
Message-ID: <j6kibf$62d$2@dough.gmane.org>

On 06-10-11 12:03, Andrea Crotti wrote:
> - a pypi server on localhost

Or just a local directory with all the .tar.gz eggs together and 
pointing find-links to that directory. (Possibly behind apache if you 
want to).


Reinout

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


From andrea.crotti.0 at gmail.com  Fri Oct  7 12:32:57 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Fri, 07 Oct 2011 11:32:57 +0100
Subject: [Distutils] buildout & develop
In-Reply-To: <CAC8tyQ40VfXuaUmCZ2-Fkvzic_8ritEpBpk97LGfhMQbmE9QwQ@mail.gmail.com>
References: <4E8D7D04.4010401@gmail.com>
	<CAC8tyQ40VfXuaUmCZ2-Fkvzic_8ritEpBpk97LGfhMQbmE9QwQ@mail.gmail.com>
Message-ID: <4E8ED559.8010204@gmail.com>

On 10/06/2011 02:07 PM, Benji York wrote:
> The "develop" option should do what you want:
> http://pypi.python.org/pypi/zc.buildout/1.5.2#work-on-a-package
I'm not sure this is exactly what I need...
I mean as a developer I have one application which uses 10 different eggs.
I want to be able to modify also what these eggs do while coding, should I
add all of them to the "develop" line?

From wichert at wiggy.net  Fri Oct  7 12:48:46 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Fri, 07 Oct 2011 12:48:46 +0200
Subject: [Distutils] buildout & develop
In-Reply-To: <4E8ED559.8010204@gmail.com>
References: <4E8D7D04.4010401@gmail.com>	<CAC8tyQ40VfXuaUmCZ2-Fkvzic_8ritEpBpk97LGfhMQbmE9QwQ@mail.gmail.com>
	<4E8ED559.8010204@gmail.com>
Message-ID: <4E8ED90E.5010708@wiggy.net>

On 10/07/2011 12:32 PM, Andrea Crotti wrote:
> I'm not sure this is exactly what I need...
> I mean as a developer I have one application which uses 10 different 
> eggs.
> I want to be able to modify also what these eggs do while coding, 
> should I
> add all of them to the "develop" line? 

Yes. I can highly recommend using mr.developer to manage this process; 
it makes it much easier to (co)develop related eggs.

WIchert.



From setuptools at bugs.python.org  Fri Oct 14 17:25:24 2011
From: setuptools at bugs.python.org (Chris Dukes)
Date: Fri, 14 Oct 2011 15:25:24 +0000
Subject: [Distutils] [issue135] Problem with bdist_rpm with rpm 3.0.5
Message-ID: <1318605924.77.0.49778568451.issue135@psf.upfronthosting.co.za>


New submission from Chris Dukes <chris.dukes.aix at gmail.com>:

I need to support bdist_rpm with the older version of RPM (3.0.5) that ships with AIX.

%install
python setup.py install --single-version-externally-managed -O1 --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES

leads to a file list ending with the egg-info directory after listing the files in the egg-info directory.

%files -f INSTALLED_FILES
%defattr(-,root,root)
RPM 3.0.5 ends up recursing the egg-info directory a second time and reporting all the files in the egg-info directory as duplicates and fails when building the RPM.

Thanks,
Chris Dukes

----------
messages: 644
nosy: chris.dukes.aix
priority: bug
status: unread
title: Problem with bdist_rpm with rpm 3.0.5

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

From aclark at aclark.net  Sun Oct 16 02:27:34 2011
From: aclark at aclark.net (Alex Clark)
Date: Sat, 15 Oct 2011 20:27:34 -0400
Subject: [Distutils] Additional trove classifiers for Plone
Message-ID: <j7d8dn$jen$1@dough.gmane.org>

Hi,


The Plone project[1] has the need for additional trove classifiers to 
track add-on compatibility by version. Is something that could be added to:

- http://pypi.python.org/pypi?%3Aaction=list_classifiers

? Or should we implement these internally?[2] Are there any 
repercussions in doing so?


Thanks for any feedback.




Alex





[1] http://plone.org

[2] https://github.com/collective/Products.PloneSoftwareCenter


-- 
Alex Clark ? http://aclark.net


From wichert at wiggy.net  Sun Oct 16 09:04:13 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Sun, 16 Oct 2011 09:04:13 +0200
Subject: [Distutils] Additional trove classifiers for Plone
In-Reply-To: <j7d8dn$jen$1@dough.gmane.org>
References: <j7d8dn$jen$1@dough.gmane.org>
Message-ID: <4E9A81ED.60603@wiggy.net>

On 2011-10-16 02:27, Alex Clark wrote:
> Hi,
>
>
> The Plone project[1] has the need for additional trove classifiers to
> track add-on compatibility by version. Is something that could be added to:
>
> - http://pypi.python.org/pypi?%3Aaction=list_classifiers
>
> ? Or should we implement these internally?[2] Are there any
> repercussions in doing so?

To be a bit more specific: the proposal is to use the same scheme as 
used to indicate Python version compatibility by extending the Plone 
framework classifier with version numbers. For example:

   Framework :: Plone :: 4.1
   Framework :: Plone :: 4.2

Wichert.

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

From martin at v.loewis.de  Sun Oct 16 11:03:50 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Oct 2011 11:03:50 +0200
Subject: [Distutils] Additional trove classifiers for Plone
In-Reply-To: <4E9A81ED.60603@wiggy.net>
References: <j7d8dn$jen$1@dough.gmane.org> <4E9A81ED.60603@wiggy.net>
Message-ID: <4E9A9DF6.6030607@v.loewis.de>

> To be a bit more specific: the proposal is to use the same scheme as
> used to indicate Python version compatibility by extending the Plone
> framework classifier with version numbers. For example:
> 
>   Framework :: Plone :: 4.1
>   Framework :: Plone :: 4.2

Can you please be even more specific? Someone please provide an exact,
complete list. I have no clue what version numbers Plone uses.

Regards,
Martin

From aclark at aclark.net  Sun Oct 16 13:04:26 2011
From: aclark at aclark.net (Alex Clark)
Date: Sun, 16 Oct 2011 07:04:26 -0400
Subject: [Distutils] Additional trove classifiers for Plone
In-Reply-To: <4E9A9DF6.6030607@v.loewis.de>
References: <j7d8dn$jen$1@dough.gmane.org> <4E9A81ED.60603@wiggy.net>
	<4E9A9DF6.6030607@v.loewis.de>
Message-ID: <j7ednp$bdk$1@dough.gmane.org>

On 10/16/11 5:03 AM, "Martin v. L?wis" wrote:
>> To be a bit more specific: the proposal is to use the same scheme as
>> used to indicate Python version compatibility by extending the Plone
>> framework classifier with version numbers. For example:
>>
>>    Framework :: Plone :: 4.1
>>    Framework :: Plone :: 4.2
>
> Can you please be even more specific? Someone please provide an exact,
> complete list. I have no clue what version numbers Plone uses.

Sure, something like this:

   Framework :: Plone :: 1.0
   Framework :: Plone :: 2.0
   Framework :: Plone :: 2.1
   Framework :: Plone :: 2.5
   Framework :: Plone :: 3.0
   Framework :: Plone :: 3.1
   Framework :: Plone :: 3.2
   Framework :: Plone :: 3.3
   Framework :: Plone :: 4.0
   Framework :: Plone :: 4.1
   Framework :: Plone :: 4.2

But let me run this by plone-dev, to get some more 
feedback/confirmation; I'll get back to you with the exact/complete list.


Thanks,


Alex




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


-- 
Alex Clark ? http://aclark.net


From martin at v.loewis.de  Sun Oct 16 19:19:21 2011
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 16 Oct 2011 19:19:21 +0200
Subject: [Distutils] Additional trove classifiers for Plone
In-Reply-To: <j7ednp$bdk$1@dough.gmane.org>
References: <j7d8dn$jen$1@dough.gmane.org>
	<4E9A81ED.60603@wiggy.net>	<4E9A9DF6.6030607@v.loewis.de>
	<j7ednp$bdk$1@dough.gmane.org>
Message-ID: <4E9B1219.6010606@v.loewis.de>

> But let me run this by plone-dev, to get some more
> feedback/confirmation; I'll get back to you with the exact/complete list.

Please also verify that they are all needed. Minimality is an objective,
so if some plone versions are out-of-date, there is no point in adding a
classifier.

Regards,
Martin

From aclark at aclark.net  Mon Oct 17 15:00:15 2011
From: aclark at aclark.net (Alex Clark)
Date: Mon, 17 Oct 2011 09:00:15 -0400
Subject: [Distutils] Additional trove classifiers for Plone
In-Reply-To: <4E9B1219.6010606@v.loewis.de>
References: <j7d8dn$jen$1@dough.gmane.org>
	<4E9A81ED.60603@wiggy.net>	<4E9A9DF6.6030607@v.loewis.de>
	<j7ednp$bdk$1@dough.gmane.org> <4E9B1219.6010606@v.loewis.de>
Message-ID: <j7h8sv$7sf$1@dough.gmane.org>

On 10/16/11 1:19 PM, "Martin v. L?wis" wrote:
>> But let me run this by plone-dev, to get some more
>> feedback/confirmation; I'll get back to you with the exact/complete list.
>
> Please also verify that they are all needed. Minimality is an objective,
> so if some plone versions are out-of-date, there is no point in adding a
> classifier.


OK Here is the list:


    Framework :: Plone :: 3.3
    Framework :: Plone :: 4.0
    Framework :: Plone :: 4.1
    Framework :: Plone :: 4.2
    Framework :: Plone :: 4.3


(3.3 was the first Plone version to be distributed as an egg. And 4.3 is 
as far in the future as we know about right now.)

To answer the other two questions (I found on the catalog list, sorry, I 
guess I should have asked there.)

* what specific semantics would you imply for packages tagged with these 
classifiers?

	These classifiers imply compatibility with a particular Plone release. 
For example, we have add-ons that only work with 4.0 (and not 4.1, etc).

* what specific packages that are already on PyPI would be tagged with
these specific classifiers?

	Anyone releasing Plone add-ons to PyPI will now be able to specify 
Plone version compatibility in setup.py. I suspect that most, if not 
all, actively maintained add-ons will make use of this classifier e.g. 
http://pypi.python.org/pypi/Products.PloneFormGen. But there are too 
many to list. Note Plone core packages may or may not make use of these 
classifiers. They could, but the request is made explicitly on behalf of 
add-on developers.


Thank you for considering,



Alex







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


-- 
Alex Clark ? http://aclark.net


From alanhaggai at alanhaggai.org  Mon Oct 17 19:50:00 2011
From: alanhaggai at alanhaggai.org (Alan Haggai Alavi)
Date: Mon, 17 Oct 2011 23:20:00 +0530
Subject: [Distutils] [Bug] Zip: Compressed size is set to a non-zero value
 when uncompressed size is set to zero
Message-ID: <CA+W-e=7KDPvhwtbCh=qfpBqbMNm4X5vQK-CPOLvp8LMTENT08g@mail.gmail.com>

Hello,

.ZIP archive generation using setuptools seems to generate an invalid
archive. The attached archive was created with setuptools:
python setup.py sdist --format=zip

Analysing the hexdump and Zip-Parser's (https://github.com/alanhaggai/
Zip-Parser) output (attached file: zip_parser.out) it seems that the
archive is corrupt. In its local file header and central directory
file header for Foo-0.2.0/bar/__init__.py, compressed size is set to 2
(the compressed data being 0x03 and 0x00). Uncompressed size is set to
0! This has been confirmed using Ark (KDE archiving tool) and a
snapshot has been attached.

More details can be read at the bug reported against Archive::Zip Perl
module - https://rt.cpan.org/Public/Bug/Display.html?id=68446

When zipfile was used to create the archive (that is, without using
setuptools) this faulty behavior was not noticed.

Please let me know if there is anyway that I can help.

Attachment files:
  - http://alanhaggai.org/files/Foo-0.2.0.zip
  - http://alanhaggai.org/files/ark.png
  - http://alanhaggai.org/files/zip_parser.out

Regards,
Alan Haggai Alavi.
-- 
The difference makes the difference.

From pje at telecommunity.com  Tue Oct 18 02:34:27 2011
From: pje at telecommunity.com (PJ Eby)
Date: Mon, 17 Oct 2011 20:34:27 -0400
Subject: [Distutils] [Bug] Zip: Compressed size is set to a non-zero
 value when uncompressed size is set to zero
In-Reply-To: <CA+W-e=7KDPvhwtbCh=qfpBqbMNm4X5vQK-CPOLvp8LMTENT08g@mail.gmail.com>
References: <CA+W-e=7KDPvhwtbCh=qfpBqbMNm4X5vQK-CPOLvp8LMTENT08g@mail.gmail.com>
Message-ID: <CALeMXf4N_mN1Ou5KdQpFgaUNkEfz7MY7R8sbCJYX6uSJi+is7g@mail.gmail.com>

On Mon, Oct 17, 2011 at 1:50 PM, Alan Haggai Alavi <
alanhaggai at alanhaggai.org> wrote:

> When zipfile was used to create the archive (that is, without using
> setuptools) this faulty behavior was not noticed.
>

Does it occur with plain distutils (i.e., no setuptools)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111017/fea8d83d/attachment.html>

From alanhaggai at alanhaggai.org  Wed Oct 19 19:12:03 2011
From: alanhaggai at alanhaggai.org (Alan Haggai Alavi)
Date: Wed, 19 Oct 2011 22:42:03 +0530
Subject: [Distutils] [Bug] Zip: Compressed size is set to a non-zero
 value when uncompressed size is set to zero
In-Reply-To: <CALeMXf4N_mN1Ou5KdQpFgaUNkEfz7MY7R8sbCJYX6uSJi+is7g@mail.gmail.com>
References: <CA+W-e=7KDPvhwtbCh=qfpBqbMNm4X5vQK-CPOLvp8LMTENT08g@mail.gmail.com>
	<CALeMXf4N_mN1Ou5KdQpFgaUNkEfz7MY7R8sbCJYX6uSJi+is7g@mail.gmail.com>
Message-ID: <4E9F04E3.4020201@alanhaggai.org>

Hello,

On 10/18/11 06:04, PJ Eby wrote:
> Does it occur with plain distutils (i.e., no setuptools)?

Yes, it seems that the behaviour persists.

Regards,
Alan Haggai Alavi.
-- 
The difference makes the difference.

From m.richardson at ed.ac.uk  Thu Oct 20 17:39:41 2011
From: m.richardson at ed.ac.uk (Matthew Richardson)
Date: Thu, 20 Oct 2011 16:39:41 +0100
Subject: [Distutils] config file handling in bdist_rpm
Message-ID: <4EA040BD.4050502@ed.ac.uk>

I'm currently using the bdist_rpm method to build rpms.

I've had a look through the distutils source, and it seems to generate a
%files section in the specfile and just put everything in there.

Would it be possible to extend bdist_rpm to also use the %config section
for config files, so that these are properly identified in the rpm and
thus not removed or overwritten on rpm changes?

Thanks,

Matthew


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

From chris at simplistix.co.uk  Fri Oct 21 19:39:18 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Fri, 21 Oct 2011 18:39:18 +0100
Subject: [Distutils] [buildout-versions] Can buildout-versions made to
 work for zc.buildout v1.4.*? (#1)
In-Reply-To: <Simplistix/buildout-versions/issues/1@github.com>
References: <Simplistix/buildout-versions/issues/1@github.com>
Message-ID: <4EA1AE46.7020602@simplistix.co.uk>

Hi Wouter,

On 20/10/2011 18:58, Wouter Vanden Hove wrote:
> I have not delved deep in to buildout-extensions, but  why can buildout.dumppickedversions be used with zc.buildout v1.4.*
> while buildout-versions requires  1.5.0?

buildout-versions has a bit more functionality that 
buildout.dumppickedversions now ;-)

> is it doable  to add compatibility for zc.buildout  v1.4.*?

What's stopping you moving to buildout 1.5?

Chris

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

From wichert at wiggy.net  Fri Oct 21 21:34:33 2011
From: wichert at wiggy.net (Wichert Akkerman)
Date: Fri, 21 Oct 2011 21:34:33 +0200
Subject: [Distutils] [buildout-versions] Can buildout-versions made to
 work for zc.buildout v1.4.*? (#1)
In-Reply-To: <4EA1AE46.7020602@simplistix.co.uk>
References: <Simplistix/buildout-versions/issues/1@github.com>
	<4EA1AE46.7020602@simplistix.co.uk>
Message-ID: <4EA1C949.20200@wiggy.net>

On 2011-10-21 19:39, Chris Withers wrote:
>> is it doable to add compatibility for zc.buildout v1.4.*?
>
> What's stopping you moving to buildout 1.5?

In my experience buildout 1.5 fails badly on some newer ubuntu systems, 
while buildout 1.4 still works flawlessly.

Wichert.

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

From blueeagle2 at gmail.com  Sun Oct 23 09:16:58 2011
From: blueeagle2 at gmail.com (blueeagle2 at gmail.com)
Date: Sun, 23 Oct 2011 00:16:58 -0700
Subject: [Distutils] Search option and easy_install
Message-ID: <CAAttMS1EK_wQyT2khcWRHumH0MQ8ZjbqQ9-RnyyPyUCFqKSsXw@mail.gmail.com>

I was wondering if easy_install has a search option so I can find the
packages I need to install.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111023/97da7fb0/attachment.html>

From pje at telecommunity.com  Sun Oct 23 20:45:14 2011
From: pje at telecommunity.com (PJ Eby)
Date: Sun, 23 Oct 2011 14:45:14 -0400
Subject: [Distutils] Search option and easy_install
In-Reply-To: <CAAttMS1EK_wQyT2khcWRHumH0MQ8ZjbqQ9-RnyyPyUCFqKSsXw@mail.gmail.com>
References: <CAAttMS1EK_wQyT2khcWRHumH0MQ8ZjbqQ9-RnyyPyUCFqKSsXw@mail.gmail.com>
Message-ID: <CALeMXf48oMe=BE5uF+F28fFqYejMUycD+MAb93vg3iTwbEqFaA@mail.gmail.com>

On Sun, Oct 23, 2011 at 3:16 AM, <blueeagle2 at gmail.com> wrote:

> I was wondering if easy_install has a search option so I can find the
> packages I need to install.
>
>
If you don't know what package you want to install, you should probably
visit http://pypi.python.org/ and use the search function there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111023/2e372991/attachment.html>

From chris at simplistix.co.uk  Mon Oct 24 19:30:05 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 24 Oct 2011 18:30:05 +0100
Subject: [Distutils] [buildout-versions] Can buildout-versions made to
 work for zc.buildout v1.4.*? (#1)
In-Reply-To: <Simplistix/buildout-versions/issues/1/2484621@github.com>
References: <Simplistix/buildout-versions/issues/1@github.com>
	<Simplistix/buildout-versions/issues/1/2484621@github.com>
Message-ID: <4EA5A09D.1080900@simplistix.co.uk>

On 21/10/2011 19:29, Wouter Vanden Hove wrote:
> 1) Plone is officially still using zc.buildout 1.4.*
>     see for example  http://dist.plone.org/release/4.1.2/versions.cfg  refers to
>     http://download.zope.org/Zope2/index/2.13.10/versions.cfg  which refers to
>     http://download.zope.org/zopetoolkit/index/1.0.4/ztk-versions.cfg
>     -->  zc.buildout = 1.4.4

Yeah, but you'll be fine to specify a newer version of buildout, eg:

[buildout]
extends = http://dist.plone.org/release/4.1.2/versions.cfg
version = versions

[versions]
zc.buildout = 1.5.whatever

> 2) unrelated to that, I'd like to have my buildout-directories as a virtualenv
>     but  virtualenv conflicts with zc.buildout>=1.5
>     see  http://mail.python.org/pipermail/distutils-sig/2010-April/016062.html

Well, this is kind of irrelevant, buildout 1.5 makes wrapping the 
buildout in a virtualenv unnecessary...

cheers,

Chris

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

From chris at simplistix.co.uk  Mon Oct 24 19:37:26 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Mon, 24 Oct 2011 18:37:26 +0100
Subject: [Distutils] [buildout-versions] Can buildout-versions made to
 work for zc.buildout v1.4.*? (#1)
In-Reply-To: <20111021223511.GG1609@localhost>
References: <Simplistix/buildout-versions/issues/1@github.com>
	<4EA1AE46.7020602@simplistix.co.uk>
	<20111021223511.GG1609@localhost>
Message-ID: <4EA5A256.3040401@simplistix.co.uk>

On 21/10/2011 23:35, Jonathan Ballet wrote:
> I never used buildout-versions, but buildout.dumppickedversions is quite
> buggy IMO.

Yeah, it's one of the reasons why I forked it...

> I worked a bit to make the output more stable over successive run: my
> use case was to bootstrap a project and keep using the same dependencies
> and versions (no matter what they were in the beginning) as long as i
> didn't change the versions.cfg file.

Yeah, that's how buildout-versions works, I'd encourage you to give it a 
try and let me know if you hit any problems...

> But there are many other corner cases that aren't detected by the
> extension, and the tests are so long to run and so dependant on
> setuptools or distribute that I stopped working on it and stopped using
> it also. If I would need such functionality again, I will head towards
> buildout-versions instead...

buzzkill:buildout-versions chris$ bin/test -v
Running tests at level 1
Running zope.testrunner.layer.UnitTests tests:
   Set up zope.testrunner.layer.UnitTests in 0.000 seconds.
   Running:
...............................................
   Ran 47 tests with 0 failures and 0 errors in 17.296 seconds.
Tearing down left over layers:
   Tear down zope.testrunner.layer.UnitTests in 0.000 seconds.

There is one slow test in there, but I don't think that's outrageously 
slow...

cheers,

Chris

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

From andrea.crotti.0 at gmail.com  Tue Oct 25 12:05:26 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Tue, 25 Oct 2011 11:05:26 +0100
Subject: [Distutils] virtualenv & pypi-server
Message-ID: <4EA689E6.4020506@gmail.com>

After reading everything was possible to read on setuptools and friends,
I'm a bit confused...

I have the following situation:
suppose that there is a framework composed by many many eggs, which
doesn't change very often.

Then there are N applications using this framework, where every
application is also composed by 2-3 eggs, and everything is run in a
"funny" way (using Envisage).

So at the moment every application fiddles around with the global
easy_install.pth, which is bad and needs to be changed, and I have to
figure out how.

My idea would be to
- have a global pypi-server running on localhost
- every application is in a virtualenv (or buildout environment) and
   uses this local pypi-server

I'm doing a few experiments, but already I'm not able to make my virtual
env to fetch from my local pypi-server, what is the magic setting for that?

The other future problems that I still see now are:
1. I have to be able to develop also the eggs from the framework
2. I have to make everything very simple to do from and Eclipse
3. These applications have to be shared on SVN, so maybe zc.buildout
    might be a better choice in this sense.

Thanks a lot,
Andrea

From seppo.yliolli at gmail.com  Sat Oct 22 23:41:12 2011
From: seppo.yliolli at gmail.com (Seppo Yli-Olli)
Date: Sun, 23 Oct 2011 00:41:12 +0300
Subject: [Distutils] distutils/cygwincompiler.py not compatible with new
	releases of MingW
Message-ID: <4EA33878.4000100@gmail.com>

Hi,
newer versions of MingW no longer have -mno-cygwin parameter for their 
GCC (4.6.1 here) et al which means that compiling with that out of the 
box fails. Is there some kind of bug tracker for distutils where this 
could be followed (I'd be willing to study more in-depth when this 
broke)? Assumably -mno-cygwin needs to be conditional on the compiler 
version for compiler command and linker version for linker commands so 
this fixing this will not break compatibility.
Simply removing all instances of -mno-cygwin from self.set_executables 
in Mingw32Compiler's __init__ fixed it which means it should not be 
essentially difficult to overcome as long as right conditions on when 
-mno-cygwin must be used are determined.
-
Seppo Yli-Olli

From mozbugbox at yahoo.com.au  Tue Oct 25 11:08:54 2011
From: mozbugbox at yahoo.com.au (Just Fill Bugs)
Date: Tue, 25 Oct 2011 17:08:54 +0800
Subject: [Distutils] Correct way to include (debian) program icons.
In-Reply-To: <20110915185048.1425b66e@jabbar>
References: <20110912165500.0b66f752@jabbar> <20110915144628.GX16705@piotro.eu>
	<20110915185048.1425b66e@jabbar>
Message-ID: <j85uba$bl8$1@dough.gmane.org>

On 09/16/2011 12:50 AM, Mac Ryan wrote:

> 	having an icon for a running program it's hardly
> a debian-specific thing: more or less any OS have icons for
> programs, so it seemed a candidate good enough to have been put in the
> abstraction layer represented by setup.py.
>

I'm thinking subclass the install command to write a myapp_config.py 
file which contains all the installation options. The myapp_config.py 
should then be installed with the program package.

In the program, just import myapp_config and find application data under

   os.path.join(myapp_config.prefix, "share/myapp/pixmaps/....")

Don't know how to make this sheme works with .eggs.

Most python GUI programs use some crude hacks to find their UI data. 
Others simply use Makefile files.

All the distutil documents/tutorials avoid to talk about this problem.


From andrea.crotti.0 at gmail.com  Tue Oct 25 14:54:36 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Tue, 25 Oct 2011 13:54:36 +0100
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <4EA689E6.4020506@gmail.com>
References: <4EA689E6.4020506@gmail.com>
Message-ID: <4EA6B18C.8090402@gmail.com>

On 10/25/2011 11:05 AM, Andrea Crotti wrote:
> After reading everything was possible to read on setuptools and friends,
> I'm a bit confused...
>
> I have the following situation:
> suppose that there is a framework composed by many many eggs, which
> doesn't change very often.
>
> Then there are N applications using this framework, where every
> application is also composed by 2-3 eggs, and everything is run in a
> "funny" way (using Envisage).
>
> So at the moment every application fiddles around with the global
> easy_install.pth, which is bad and needs to be changed, and I have to
> figure out how.
>
> My idea would be to
> - have a global pypi-server running on localhost
> - every application is in a virtualenv (or buildout environment) and
>   uses this local pypi-server
>
> I'm doing a few experiments, but already I'm not able to make my virtual
> env to fetch from my local pypi-server, what is the magic setting for 
> that?
>
> The other future problems that I still see now are:
> 1. I have to be able to develop also the eggs from the framework
> 2. I have to make everything very simple to do from and Eclipse
> 3. These applications have to be shared on SVN, so maybe zc.buildout
>    might be a better choice in this sense.
>
> Thanks a lot,
> Andrea

This link answers
http://jacobian.org/writing/when-pypi-goes-down/
to one of my questions, so now I know at least how to configure buildout and
globally easy_install...


From markmc at redhat.com  Tue Oct 25 15:19:38 2011
From: markmc at redhat.com (Mark McLoughlin)
Date: Tue, 25 Oct 2011 14:19:38 +0100
Subject: [Distutils] Problem pip installing sqlalchemy-migrate with latest
	distribute
Message-ID: <1319548779.2143.44.camel@sorcha>

Hey,

I've just reported this sqlalchemy-migrate issue:

  http://code.google.com/p/sqlalchemy-migrate/issues/detail?id=131

I thought it was worth pointing out here in case anyone thinks it's not
an sqlalchemy-migrate specific issue.

Cheers,
Mark.


From andrea.crotti.0 at gmail.com  Tue Oct 25 16:50:11 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Tue, 25 Oct 2011 15:50:11 +0100
Subject: [Distutils] virtualenv error
Message-ID: <4EA6CCA3.6020609@gmail.com>

I just simply try to run
"virtualenv -p python2.7 app"
and I get this error:

Renaming 
/usr/lib/python2.7/site-packages/setuptools_git-0.4.2-py2.7.egg-info 
into 
/usr/lib/python2.7/site-packages/setuptools_git-0.4.2-py2.7.egg-info.OLD.1319554103.83
error: Permission denied

But why does it try to change something system-wide if I just run it as 
a normal user?
I have never seen this kind of error before, any hint?

From merwok at netwok.org  Tue Oct 25 17:37:38 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 25 Oct 2011 17:37:38 +0200
Subject: [Distutils] distutils/cygwincompiler.py not compatible with new
 releases of MingW
In-Reply-To: <4EA33878.4000100@gmail.com>
References: <4EA33878.4000100@gmail.com>
Message-ID: <4EA6D7C2.6050003@netwok.org>

Hi Seppo,

> newer versions of MingW no longer have -mno-cygwin parameter for their 
> GCC (4.6.1 here) et al which means that compiling with that out of the 
> box fails. Is there some kind of bug tracker for distutils where this 
> could be followed (I'd be willing to study more in-depth when this 
> broke)?

Here it is: http://bugs.python.org/issue12641

We need to tread carefully with the distutils codebase, as many setup
scripts out there depend on undocumented behavior or work around bugs.
For this issue, I don?t have enough information to decide whether to do
a version check, call gcc -dumpspecs or remove the option altogether.

Cheers

From andrea.crotti.0 at gmail.com  Tue Oct 25 16:51:11 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Tue, 25 Oct 2011 15:51:11 +0100
Subject: [Distutils] virtualenv error
In-Reply-To: <4EA6CCA3.6020609@gmail.com>
References: <4EA6CCA3.6020609@gmail.com>
Message-ID: <4EA6CCDF.1000204@gmail.com>

On 10/25/2011 03:50 PM, Andrea Crotti wrote:
> I just simply try to run
> "virtualenv -p python2.7 app"
> and I get this error:
>
> Renaming 
> /usr/lib/python2.7/site-packages/setuptools_git-0.4.2-py2.7.egg-info 
> into 
> /usr/lib/python2.7/site-packages/setuptools_git-0.4.2-py2.7.egg-info.OLD.1319554103.83
> error: Permission denied
>
> But why does it try to change something system-wide if I just run it 
> as a normal user?
> I have never seen this kind of error before, any hint?

Sorry sorry, my fault, "virtualenv" was already the python3 version, 
while I should run
virtualenv2 to install python2 virtual environments..

From chris at simplistix.co.uk  Tue Oct 25 19:52:25 2011
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 25 Oct 2011 18:52:25 +0100
Subject: [Distutils] [buildout-versions] Can buildout-versions made to
 work for zc.buildout v1.4.*? (#1)
In-Reply-To: <4EA1C949.20200@wiggy.net>
References: <Simplistix/buildout-versions/issues/1@github.com>
	<4EA1AE46.7020602@simplistix.co.uk> <4EA1C949.20200@wiggy.net>
Message-ID: <4EA6F759.7030903@simplistix.co.uk>

On 21/10/2011 20:34, Wichert Akkerman wrote:
> On 2011-10-21 19:39, Chris Withers wrote:
>>> is it doable to add compatibility for zc.buildout v1.4.*?
>>
>> What's stopping you moving to buildout 1.5?
>
> In my experience buildout 1.5 fails badly on some newer ubuntu systems,
> while buildout 1.4 still works flawlessly.

Hmm, well, buildout-versions is up on GitHub, I wonder whether someone 
could work up a branch that works with buildout 1.4?

It may just be a case of relaxing the requirement in setup.py, running 
the tests and seeing what happens...

cheers,

Chris

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

From pje at telecommunity.com  Tue Oct 25 19:57:21 2011
From: pje at telecommunity.com (PJ Eby)
Date: Tue, 25 Oct 2011 13:57:21 -0400
Subject: [Distutils] Problem pip installing sqlalchemy-migrate with
	latest distribute
In-Reply-To: <1319548779.2143.44.camel@sorcha>
References: <1319548779.2143.44.camel@sorcha>
Message-ID: <CALeMXf5KHdG-n9xEmn-45yq=8nAiH8vBxfNY25do0ZWw7CnwYQ@mail.gmail.com>

On Tue, Oct 25, 2011 at 9:19 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> Hey,
>
> I've just reported this sqlalchemy-migrate issue:
>
>  http://code.google.com/p/sqlalchemy-migrate/issues/detail?id=131
>
> I thought it was worth pointing out here in case anyone thinks it's not
> an sqlalchemy-migrate specific issue.
>

It's not.   https://bitbucket.org/tarek/distribute/issue/208 is an incorrect
fix; the pkg_resources code was correct, and the documentation was wrong.
 So distribute 0.6.23 actually introduces a bug, relative to setuptools.

As it happens, the behavior described in the doc was changed a long time ago
because people weren't reading the docs and packages existed in the field
using '-rc' tags, so I fixed the problem in pkg_resources, but missed that
there was a reference in setuptools.txt to this behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111025/6bf1ecd7/attachment.html>

From pje at telecommunity.com  Tue Oct 25 22:59:46 2011
From: pje at telecommunity.com (PJ Eby)
Date: Tue, 25 Oct 2011 16:59:46 -0400
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <4EA689E6.4020506@gmail.com>
References: <4EA689E6.4020506@gmail.com>
Message-ID: <CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>

On Tue, Oct 25, 2011 at 6:05 AM, Andrea Crotti <andrea.crotti.0 at gmail.com>wrote:

> I have the following situation:
> suppose that there is a framework composed by many many eggs, which
> doesn't change very often.
>
> Then there are N applications using this framework, where every
> application is also composed by 2-3 eggs, and everything is run in a
> "funny" way (using Envisage).
>
> So at the moment every application fiddles around with the global
> easy_install.pth, which is bad and needs to be changed, and I have to
> figure out how.
>

If you use the "-m" option to easy_install, the easy-install.pth won't be
changed (or even created, if it doesn't exist).  Instead, the application
scripts will simply add the needed eggs to their path at runtime.

This is the most flexible approach; the only downside to it is if you just
start a Python interpreter, none of the eggs will be on sys.path unless you
explicitly pkg_resources.require() them.  But for stable app deployment, or
even app development (using "setup.py develop" or "setup.py test") it works
rather well.



> The other future problems that I still see now are:
> 1. I have to be able to develop also the eggs from the framework
>

Use "setup.py develop -m" to install a project in development mode, without
altering easy-install.pth.  Any changes made in the source then take effect
immediately in the target environment.


> 2. I have to make everything very simple to do from and Eclipse
>

The "develop" command only needs to be re-run if you change your setup.py
options or your dependencies, so it's not hard to do.



> 3. These applications have to be shared on SVN, so maybe zc.buildout
>   might be a better choice in this sense.
>
>
To me buildout sounds like overkill - I have a whole bunch of projects I
develop that are installed with "setup.py develop" on my development
machine.  Any changes I make to the source are immediately seen by any other
projects sharing the same targeted installation directory.



> Thanks a lot,
> Andrea
> ______________________________**_________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/**mailman/listinfo/distutils-sig<http://mail.python.org/mailman/listinfo/distutils-sig>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111025/5cf4081d/attachment.html>

From andrea.crotti.0 at gmail.com  Wed Oct 26 12:21:21 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Wed, 26 Oct 2011 11:21:21 +0100
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
Message-ID: <4EA7DF21.3090308@gmail.com>

On 10/25/2011 09:59 PM, PJ Eby wrote:
>
> If you use the "-m" option to easy_install, the easy-install.pth won't 
> be changed (or even created, if it doesn't exist).  Instead, the 
> application scripts will simply add the needed eggs to their path at 
> runtime.
>
> This is the most flexible approach; the only downside to it is if you 
> just start a Python interpreter, none of the eggs will be on sys.path 
> unless you explicitly pkg_resources.require() them.  But for stable 
> app deployment, or even app development (using "setup.py develop" or 
> "setup.py test") it works rather well.
>

Thanks a lot, that might be a nice solution.
Reading the doc I would have never guessed it since "-m" stands for 
multi-version...

Anyway the other problem is that our applications are actually Envisage 
applications (which have plugin
discovery at run-time) which complicates things a little bit.
I'll try to make a trivial example and see if it might work...

However, I still need a pypi-server running on localhost to discover all 
the eggs I might need to require, is that correct?


>
> To me buildout sounds like overkill - I have a whole bunch of projects 
> I develop that are installed with "setup.py develop" on my development 
> machine.  Any changes I make to the source are immediately seen by any 
> other projects sharing the same targeted installation directory.

Yes maybe it's a bit overkill, and involves more complexity, I'll first 
try the "easy" way...

From andrea.crotti.0 at gmail.com  Wed Oct 26 15:22:55 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Wed, 26 Oct 2011 14:22:55 +0100
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
Message-ID: <4EA809AF.5000807@gmail.com>

On 10/25/2011 09:59 PM, PJ Eby wrote:
>
>
> If you use the "-m" option to easy_install, the easy-install.pth won't 
> be changed (or even created, if it doesn't exist).  Instead, the 
> application scripts will simply add the needed eggs to their path at 
> runtime.
>
> This is the most flexible approach; the only downside to it is if you 
> just start a Python interpreter, none of the eggs will be on sys.path 
> unless you explicitly pkg_resources.require() them.  But for stable 
> app deployment, or even app development (using "setup.py develop" or 
> "setup.py test") it works rather well.
>

Another thing, how should I call a setup.py from python itself?
I don't like too much the idea of using subprocess to pass arguments to 
something which
is already in python, but it appears that this is how it's done...

I've also seen doing for example
sys.argv = ['develop']
execfile('setup.py')

which also doesn't look very nice.

And last thing, do you have any example of using "-m" and where/how I 
have to
require the needed packages with pkg_resources?

From pje at telecommunity.com  Wed Oct 26 16:19:34 2011
From: pje at telecommunity.com (PJ Eby)
Date: Wed, 26 Oct 2011 10:19:34 -0400
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <4EA7DF21.3090308@gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
	<4EA7DF21.3090308@gmail.com>
Message-ID: <CALeMXf7Z4jchea8y-PzqK8n3jeNNCSbA-O1uOtOzfwTqQnzcBw@mail.gmail.com>

On Wed, Oct 26, 2011 at 6:21 AM, Andrea Crotti <andrea.crotti.0 at gmail.com>wrote:

> On 10/25/2011 09:59 PM, PJ Eby wrote:
>
>>
>> If you use the "-m" option to easy_install, the easy-install.pth won't be
>> changed (or even created, if it doesn't exist).  Instead, the application
>> scripts will simply add the needed eggs to their path at runtime.
>>
>> This is the most flexible approach; the only downside to it is if you just
>> start a Python interpreter, none of the eggs will be on sys.path unless you
>> explicitly pkg_resources.require() them.  But for stable app deployment, or
>> even app development (using "setup.py develop" or "setup.py test") it works
>> rather well.
>>
>>
> Thanks a lot, that might be a nice solution.
> Reading the doc I would have never guessed it since "-m" stands for
> multi-version...
>
> Anyway the other problem is that our applications are actually Envisage
> applications (which have plugin
> discovery at run-time) which complicates things a little bit.
> I'll try to make a trivial example and see if it might work...
>
> However, I still need a pypi-server running on localhost to discover all
> the eggs I might need to require, is that correct?


Why would you need that?

As long as the eggs are present in a sys.path directory, the normal
pkg_resources machinery will find them.

If you mean you want to be able to test installation and deployment, or you
are continually rebuilding your install directory for some other reason,
then once again you don't need a PyPI server - just put all the eggs in a
directory somewhere and use the --find-links (-f) option to easy_install to
specify that directory name.  It will then copy them from there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111026/77291ec9/attachment.html>

From pje at telecommunity.com  Wed Oct 26 16:24:44 2011
From: pje at telecommunity.com (PJ Eby)
Date: Wed, 26 Oct 2011 10:24:44 -0400
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <4EA809AF.5000807@gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
	<4EA809AF.5000807@gmail.com>
Message-ID: <CALeMXf4FA83hURsA++LNxABj8D7Cd0AHUqsG=eB0FgB_bGdHeg@mail.gmail.com>

On Wed, Oct 26, 2011 at 9:22 AM, Andrea Crotti <andrea.crotti.0 at gmail.com>wrote:

> On 10/25/2011 09:59 PM, PJ Eby wrote:
>
>>
>>
>> If you use the "-m" option to easy_install, the easy-install.pth won't be
>> changed (or even created, if it doesn't exist).  Instead, the application
>> scripts will simply add the needed eggs to their path at runtime.
>>
>> This is the most flexible approach; the only downside to it is if you just
>> start a Python interpreter, none of the eggs will be on sys.path unless you
>> explicitly pkg_resources.require() them.  But for stable app deployment, or
>> even app development (using "setup.py develop" or "setup.py test") it works
>> rather well.
>>
>>
> Another thing, how should I call a setup.py from python itself?
> I don't like too much the idea of using subprocess to pass arguments to
> something which
> is already in python, but it appears that this is how it's done...
>
> I've also seen doing for example
> sys.argv = ['develop']
> execfile('setup.py')
>
> which also doesn't look very nice.
>
> And last thing, do you have any example of using "-m" and where/how I have
> to
> require the needed packages with pkg_resources?
>

See the official setuptools documentation links at
http://pypi.python.org/pypi/setuptools#using-setuptools-and-easyinstall

(Note, however, that if your application consists of scripts that you run
from a location they were installed to with either setup.py develop or
easy_install, then you don't need to require() them; just list them in your
setup.py's install_requires.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111026/e2ff575d/attachment.html>

From chris.jerdonek at gmail.com  Thu Oct 27 14:22:28 2011
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Thu, 27 Oct 2011 05:22:28 -0700
Subject: [Distutils] question re: easy_install and macports
Message-ID: <CAOTb1wf9JpwBTxqwmF8GHMC1v3vmHmkDeO7REjeOysnxy_p7-g@mail.gmail.com>

Hi, I have a quick question regarding easy_install and MacPorts.  I
tried easy_installing nose while using MacPorts (Python 2.6.7 /
py26-distribute @0.6.24_0 / MacPorts version 2.0.3) --

> sudo python -m easy_install nose

This worked, except it installed the nosetests script into--

/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin

but did not create an alias in--

/opt/local/bin

So nosetests is not automatically in the path.  Was this a problem
with MacPorts, easy_install, or nose?  Whose responsibility was it to
create the alias?

Thanks a lot,
--Chris

From andrea.crotti.0 at gmail.com  Thu Oct 27 15:12:59 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Thu, 27 Oct 2011 14:12:59 +0100
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <CALeMXf7Z4jchea8y-PzqK8n3jeNNCSbA-O1uOtOzfwTqQnzcBw@mail.gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
	<4EA7DF21.3090308@gmail.com>
	<CALeMXf7Z4jchea8y-PzqK8n3jeNNCSbA-O1uOtOzfwTqQnzcBw@mail.gmail.com>
Message-ID: <4EA958DB.7030003@gmail.com>

On 10/26/2011 03:19 PM, PJ Eby wrote:
> Why would you need that?
>
> As long as the eggs are present in a sys.path directory, the normal 
> pkg_resources machinery will find them.
>
> If you mean you want to be able to test installation and deployment, 
> or you are continually rebuilding your install directory for some 
> other reason, then once again you don't need a PyPI server - just put 
> all the eggs in a directory somewhere and use the --find-links (-f) 
> option to easy_install to specify that directory name.  It will then 
> copy them from there.
>

I was convinced that I needed to add every egg to the sys.path to be 
able to import it, well if I don't
actually need the local pypi-server than even better...
I was, however, doing some experiments, and not figuring out how it works.

I created an egg_directory where I added the mock library egg, I wanted to
see if I was able to find it, and that's what I do.


from pkg_resources import working_set, Environment, Requirement
from os.path import abspath

env = Environment(abspath('egg_directory'))
env.scan()

r = Requirement.parse('mock')
print(working_set.find(r))


It actually finds something but my USER installed version, not the local 
version
in the subdirectory.
And from my understanding of the doc it should not even look for in the 
global
sys.path, am I doing something wrong?

From andrea.crotti.0 at gmail.com  Thu Oct 27 17:16:29 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Thu, 27 Oct 2011 16:16:29 +0100
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <4EA958DB.7030003@gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
	<4EA7DF21.3090308@gmail.com>
	<CALeMXf7Z4jchea8y-PzqK8n3jeNNCSbA-O1uOtOzfwTqQnzcBw@mail.gmail.com>
	<4EA958DB.7030003@gmail.com>
Message-ID: <4EA975CD.3030402@gmail.com>

Answering to myself, I was using the wrong functions for pkg_resources, and
in theory I should use find_distributions.
So I tried the following
- construct a very minimal egg with a foolproof module
- find and add to the working_set all the distributions found

for d in find_distributions('egg_directory'):
     working_set.add(d)

from foolproof import fool

And in fact in sys.path the foolproof egg is there, but then I can't still
import foolproof...
Is there anything else I need to do?

Here is what the egg look like..
   -rw-r--r--        47  27-Oct-2011  16:03:16  foolproof.py
   -rw-r--r--       291  27-Oct-2011  16:11:44  foolproof.pyc
   -rw-r--r--       153  27-Oct-2011  16:11:44  EGG-INFO/SOURCES.txt
   -rw-r--r--         1  27-Oct-2011  16:11:44  EGG-INFO/zip-safe
   -rw-r--r--       183  27-Oct-2011  16:11:44  EGG-INFO/PKG-INFO
   -rw-r--r--         1  27-Oct-2011  16:11:44  
EGG-INFO/dependency_links.txt
   -rw-r--r--        10  27-Oct-2011  16:11:44  EGG-INFO/top_level.txt

From andrea.crotti.0 at gmail.com  Thu Oct 27 17:30:01 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Thu, 27 Oct 2011 16:30:01 +0100
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <4EA975CD.3030402@gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
	<4EA7DF21.3090308@gmail.com>
	<CALeMXf7Z4jchea8y-PzqK8n3jeNNCSbA-O1uOtOzfwTqQnzcBw@mail.gmail.com>
	<4EA958DB.7030003@gmail.com> <4EA975CD.3030402@gmail.com>
Message-ID: <4EA978F9.4080903@gmail.com>

On 10/27/2011 04:16 PM, Andrea Crotti wrote:
> Answering to myself, I was using the wrong functions for 
> pkg_resources, and
> in theory I should use find_distributions.
> So I tried the following
> - construct a very minimal egg with a foolproof module
> - find and add to the working_set all the distributions found
>
> for d in find_distributions('egg_directory'):
>     working_set.add(d)
>
> from foolproof import fool

Again answering to myself with this it appears to work,
but on the pkg_resources doc
for d in find_distributions('egg_directory'):
     working_set.add(d)
     d.activate()

or an alternative is to require specifically what I want.
Now I need to try from another egg using this egg and see how setup.py
tricks work in this sense.

From pje at telecommunity.com  Thu Oct 27 17:34:53 2011
From: pje at telecommunity.com (PJ Eby)
Date: Thu, 27 Oct 2011 11:34:53 -0400
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <4EA975CD.3030402@gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
	<4EA7DF21.3090308@gmail.com>
	<CALeMXf7Z4jchea8y-PzqK8n3jeNNCSbA-O1uOtOzfwTqQnzcBw@mail.gmail.com>
	<4EA958DB.7030003@gmail.com> <4EA975CD.3030402@gmail.com>
Message-ID: <CALeMXf4C-YCcDm_qkO2GNjZ3VEFGBfDkLNWrZJixAutP=PP4jQ@mail.gmail.com>

On Thu, Oct 27, 2011 at 11:16 AM, Andrea Crotti
<andrea.crotti.0 at gmail.com>wrote:

> Answering to myself, I was using the wrong functions for pkg_resources, and
> in theory I should use find_distributions.
> So I tried the following
> - construct a very minimal egg with a foolproof module
> - find and add to the working_set all the distributions found
>
> for d in find_distributions('egg_**directory'):
>    working_set.add(d)
>
> from foolproof import fool
>
> And in fact in sys.path the foolproof egg is there, but then I can't still
> import foolproof...
> Is there anything else I need to do?
>

You're making this way too hard.  ;-)

All of the APIs you're using are low-level things, used only for advanced
plugin frameworks or installer tools.  All you need for a simple script is:

sys.path.insert(0, abspath('egg_directory'))
import pkg_resources
pkg_resources.require('foolproof')
import foolproof

(Note: if you want 'egg_directory' to override the default sys.path, it is
important that you *not* import pkg_resources until after you've set up the
path.)

Also, even the above is *completely unnecessary* as long as the script you
are running is part of a project with its own setup.py.

If your script is listed in a setup.py, and you install it with setup.py
develop or using easy_install, then setuptools creates a wrapper for your
script that does all of the pkg_resources stuff for you automatically, using
the dependences specified in your setup.py.  99% of the time, if you are
using pkg_resources for anything but accessing file resources or
implementing some sort of plugin system, you are probably doing it wrong.
 ;-)

So, the only reason I'm even listing the above require() call is just in
case you can't run those generated script wrappers easily from inside
Eclipse.  And, even if that is the case, you should still make sure your
setup.py includes those dependencies, so that when you distribute your
project the dependencies will still get installed, and a proper wrapper will
be generated during installation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111027/7f66774a/attachment.html>

From pje at telecommunity.com  Thu Oct 27 17:36:36 2011
From: pje at telecommunity.com (PJ Eby)
Date: Thu, 27 Oct 2011 11:36:36 -0400
Subject: [Distutils] question re: easy_install and macports
In-Reply-To: <CAOTb1wf9JpwBTxqwmF8GHMC1v3vmHmkDeO7REjeOysnxy_p7-g@mail.gmail.com>
References: <CAOTb1wf9JpwBTxqwmF8GHMC1v3vmHmkDeO7REjeOysnxy_p7-g@mail.gmail.com>
Message-ID: <CALeMXf7BsyHsbBCE6vUx95ns=-i=xmfZZQY5c+x_tLpN7JZ_5g@mail.gmail.com>

On Thu, Oct 27, 2011 at 8:22 AM, Chris Jerdonek <chris.jerdonek at gmail.com>wrote:

> Hi, I have a quick question regarding easy_install and MacPorts.  I
> tried easy_installing nose while using MacPorts (Python 2.6.7 /
> py26-distribute @0.6.24_0 / MacPorts version 2.0.3) --
>
> > sudo python -m easy_install nose
>
> This worked, except it installed the nosetests script into--
>
> /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin
>
> but did not create an alias in--
>
> /opt/local/bin
>
> So nosetests is not automatically in the path.  Was this a problem
> with MacPorts, easy_install, or nose?  Whose responsibility was it to
> create the alias?
>

easy_install doesn't create aliases or symlinks for such things; it just
installs where it's told to by the local distutils configuration.  You can
use the command line or standard distutils configuration to tell it where
you want scripts installed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111027/a8eb0762/attachment-0001.html>

From andrea.crotti.0 at gmail.com  Thu Oct 27 17:58:00 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Thu, 27 Oct 2011 16:58:00 +0100
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <CALeMXf4C-YCcDm_qkO2GNjZ3VEFGBfDkLNWrZJixAutP=PP4jQ@mail.gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
	<4EA7DF21.3090308@gmail.com>
	<CALeMXf7Z4jchea8y-PzqK8n3jeNNCSbA-O1uOtOzfwTqQnzcBw@mail.gmail.com>
	<4EA958DB.7030003@gmail.com> <4EA975CD.3030402@gmail.com>
	<CALeMXf4C-YCcDm_qkO2GNjZ3VEFGBfDkLNWrZJixAutP=PP4jQ@mail.gmail.com>
Message-ID: <4EA97F88.40908@gmail.com>

On 10/27/2011 04:34 PM, PJ Eby wrote:
>
> You're making this way too hard.  ;-)
>
> All of the APIs you're using are low-level things, used only for 
> advanced plugin frameworks or installer tools.  All you need for a 
> simple script is:
>
> sys.path.insert(0, abspath('egg_directory'))
> import pkg_resources
> pkg_resources.require('foolproof')
> import foolproof
>
>

Thanks, that's much better right :)
So anyway I do have to work with plugins, specifically envisage plugins.

Moreover, our applications are normally composed by more than one egg, 
and each of them has
its own setup_requires requiring a set of the global eggs.

At the moment the run system is a bit complicated and uses 
pkg_resources.find_plugins...

That said reading the API was still interesting, and for example I found the

working_set.subscribe

In theory I can register a callback function that when something is 
"found" does something,
and I thought immediately that it might be possible to hot-swap some 
plugins at run-time,
is that true doing some tricks with that, is that correct?

def mycallback(dist):
     if dist == 'name':
            # reload(dist), if anything like this can be done at all

From pje at telecommunity.com  Thu Oct 27 19:17:15 2011
From: pje at telecommunity.com (PJ Eby)
Date: Thu, 27 Oct 2011 13:17:15 -0400
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <4EA97F88.40908@gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
	<4EA7DF21.3090308@gmail.com>
	<CALeMXf7Z4jchea8y-PzqK8n3jeNNCSbA-O1uOtOzfwTqQnzcBw@mail.gmail.com>
	<4EA958DB.7030003@gmail.com> <4EA975CD.3030402@gmail.com>
	<CALeMXf4C-YCcDm_qkO2GNjZ3VEFGBfDkLNWrZJixAutP=PP4jQ@mail.gmail.com>
	<4EA97F88.40908@gmail.com>
Message-ID: <CALeMXf6GT9EontAfDhkTzRf9io364whwgN4yDdfZSD4iv4fiQA@mail.gmail.com>

On Thu, Oct 27, 2011 at 11:58 AM, Andrea Crotti
<andrea.crotti.0 at gmail.com>wrote:
>
> Thanks, that's much better right :)
> So anyway I do have to work with plugins, specifically envisage plugins.
>
> Moreover, our applications are normally composed by more than one egg, and
> each of them has
> its own setup_requires requiring a set of the global eggs.
>

Er, do you mean install_requires?  setup_requires is for build-time plugins
only.


At the moment the run system is a bit complicated and uses
> pkg_resources.find_plugins...
>
> That said reading the API was still interesting, and for example I found
> the
>
> working_set.subscribe
>
> In theory I can register a callback function that when something is "found"
> does something,
> and I thought immediately that it might be possible to hot-swap some
> plugins at run-time,
> is that true doing some tricks with that, is that correct?
>
> def mycallback(dist):
>    if dist == 'name':
>           # reload(dist), if anything like this can be done at all
>

Properly reloading changed code is a lot more complex than that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111027/9bdf9fea/attachment.html>

From jaraco at jaraco.com  Thu Oct 27 19:08:47 2011
From: jaraco at jaraco.com (Jason R. Coombs)
Date: Thu, 27 Oct 2011 10:08:47 -0700
Subject: [Distutils] an approach for inspectable setup scripts
Message-ID: <A2A66F57550F50449EC38E10458E27FF15D1858CB3@VA3DIAXVS381.RED001.local>

In
http://lists.idyll.org/pipermail/testing-in-python/2011-October/004447.html,
Barry Warsaw kicked off a discussion on testing various packages within the
Python Package Index (pypi). As part of this discussion, I mentioned a
technique I've been using internally for a while to write setup scripts (old
distutils/setuptools style) such that they're more robust and
introspectable.

 

Instead of writing the following in my scripts:

 

from setuptools import setup

setup(

  name = 'foo',

  install_requires = 'bar',

)

 

I write the following:

 

setup_params = dict(

  name = 'foo',

  install_requires = 'bar',

)

 

if __name__ == '__main__':

  from setuptools import setup

  setup(**setup_params)

 

While slightly more verbose, this technique has a couple of benefits. First,
it means that code traversal algorithms (such as test discovery) don't
inadvertently execute the setup script. Second, it allows the script to be
read via import or execfile without necessarily invoking the setup()
function. This allows a third-party product, such as the Cheese Taster to
open up a project and easily inspect its setup parameters. Also, you'll note
the setuptools requirement is deferred until the script is run, and isn't
necessary to construct the parameters.

 

Furthermore, if there is other side-effect behavior, it can be invoked from
inside the __main__ block.

 

 

I share this with the community for your feedback. Is there any reason this
technique shouldn't be adopted in general? Also, how can a third-party
product detect whether a setup script is safe in this way? I don't think it
would be possible in general, but perhaps packagers could include a
directive near the head to indicate such. Consider:

 

# -*- script-disposition: import-safe -*-

 

Or similar. Alternatively, a tool could be built to compile and statically
analyze the code to detect the presence of setup_params, though would be
more likely to encounter false positives. 

 

What downsides am I missing? How could this technique be improved? Would it
be difficult to take these parameters and generate package metadata
(DistributionMetadata) from it?

 

I look forward to any feedback you have.

 

Regards,

Jason R. Coombs

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111027/09fbaaa9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6448 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111027/09fbaaa9/attachment-0001.bin>

From pje at telecommunity.com  Thu Oct 27 19:44:49 2011
From: pje at telecommunity.com (PJ Eby)
Date: Thu, 27 Oct 2011 13:44:49 -0400
Subject: [Distutils] an approach for inspectable setup scripts
In-Reply-To: <A2A66F57550F50449EC38E10458E27FF15D1858CB3@VA3DIAXVS381.RED001.local>
References: <A2A66F57550F50449EC38E10458E27FF15D1858CB3@VA3DIAXVS381.RED001.local>
Message-ID: <CALeMXf4CeiPRDFHgzajph1rKZ_A2MggGY3KxvLb46w9XHzhYjw@mail.gmail.com>

On Thu, Oct 27, 2011 at 1:08 PM, Jason R. Coombs <jaraco at jaraco.com> wrote:

> How could this technique be improved?
>

Use this instead:

http://pypi.python.org/pypi/d2to1

;-)

(It's more forward-compatible with packaging/distutils2)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20111027/ea75215a/attachment.html>

From nad at acm.org  Thu Oct 27 22:23:36 2011
From: nad at acm.org (Ned Deily)
Date: Thu, 27 Oct 2011 13:23:36 -0700
Subject: [Distutils] question re: easy_install and macports
References: <CAOTb1wf9JpwBTxqwmF8GHMC1v3vmHmkDeO7REjeOysnxy_p7-g@mail.gmail.com>
Message-ID: <nad-5382F4.13233527102011@dough.gmane.org>

In article 
<CAOTb1wf9JpwBTxqwmF8GHMC1v3vmHmkDeO7REjeOysnxy_p7-g at mail.gmail.com>,
 Chris Jerdonek <chris.jerdonek at gmail.com> wrote:
> Hi, I have a quick question regarding easy_install and MacPorts.  I
> tried easy_installing nose while using MacPorts (Python 2.6.7 /
> py26-distribute @0.6.24_0 / MacPorts version 2.0.3) --
> 
> > sudo python -m easy_install nose
> 
> This worked, except it installed the nosetests script into--
> 
> /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin
> 
> but did not create an alias in--
> 
> /opt/local/bin
> 
> So nosetests is not automatically in the path.  Was this a problem
> with MacPorts, easy_install, or nose?  Whose responsibility was it to
> create the alias?

For Mac OS X Python framework builds, the easiest general solution is to 
add the framework bin directory to your shell PATH.  The python.org 
installers do that by default.  For a Macports Python, you can add 
something like:

export 
PATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin:$PAT
H

to the appropriate shell initialization profile, like .bash_profile.

-- 
 Ned Deily,
 nad at acm.org


From chris.jerdonek at gmail.com  Fri Oct 28 04:30:29 2011
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Thu, 27 Oct 2011 19:30:29 -0700
Subject: [Distutils] question re: easy_install and macports
In-Reply-To: <nad-5382F4.13233527102011@dough.gmane.org>
References: <CAOTb1wf9JpwBTxqwmF8GHMC1v3vmHmkDeO7REjeOysnxy_p7-g@mail.gmail.com>
	<nad-5382F4.13233527102011@dough.gmane.org>
Message-ID: <CAOTb1wdpG748xRui0CS5jP-LUgr_B1apggGy_FJMr+ZdhR0xUQ@mail.gmail.com>

On Thu, Oct 27, 2011 at 1:23 PM, Ned Deily <nad at acm.org> wrote:
> In article
> <CAOTb1wf9JpwBTxqwmF8GHMC1v3vmHmkDeO7REjeOysnxy_p7-g at mail.gmail.com>,
> ?Chris Jerdonek <chris.jerdonek at gmail.com> wrote:
>> Hi, I have a quick question regarding easy_install and MacPorts. ?I
>> tried easy_installing nose

>> This worked, except it installed the nosetests script into--
>>
>> /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin
>>
>> but did not create an alias in--
>>
>> /opt/local/bin
>>
> For Mac OS X Python framework builds, the easiest general solution is to
> add the framework bin directory to your shell PATH. ?The python.org
> installers do that by default. ?For a Macports Python, you can add
> something like:
>
> export
> PATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin:$PAT
> H

Thanks for the reply, Ned.  Will this approach cause problems, though,
when switching to a different Python using "port select python" --
what's the best way to handle that issue?  Also, is there any reason
why "port select python" wasn't written to swap out and add the
appropriate framework bin to your PATH, say, immediately after
/opt/local/bin?

Thanks again,
--Chris

From chris.jerdonek at gmail.com  Fri Oct 28 04:43:57 2011
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Thu, 27 Oct 2011 19:43:57 -0700
Subject: [Distutils] easy_install execution question
Message-ID: <CAOTb1wfCN2AgbeS-Qv9EbqOBTR=8bTDH5b_yKw_vAGr9mqd8mg@mail.gmail.com>

Hi, I have one more question for the time being.  This regards how the
easy_install script works.

I use Mac OSX, and my /usr/bin directory contains three versions of
the easy_install script: easy_install, easy_install-2.5, and
easy_install-2.6.

Based on some debugging lines I tried inserting, when I execute the
script called simply "easy_install", the script seems to execute just
the first line (namely "#!/usr/bin/python"), and then seems to
immediately jump to executing easy_install-2.6.

I was curious about the mechanism that allows the Python interpreter
to jump mysteriously from one file to another.  This doesn't seem to
be evident from the easy_install scripts themselves.  What causes this
behavior?

Thanks,
--Chris

From pivanov314 at gmail.com  Fri Oct 28 07:54:39 2011
From: pivanov314 at gmail.com (Paul Ivanov)
Date: Thu, 27 Oct 2011 22:54:39 -0700
Subject: [Distutils] easy_install execution question
In-Reply-To: <CAOTb1wfCN2AgbeS-Qv9EbqOBTR=8bTDH5b_yKw_vAGr9mqd8mg@mail.gmail.com>
References: <CAOTb1wfCN2AgbeS-Qv9EbqOBTR=8bTDH5b_yKw_vAGr9mqd8mg@mail.gmail.com>
Message-ID: <CAKCGbV4u_2mE3TTa6TLAGj+WB5pM1fT0gKtiywin9XZXMnfPKw@mail.gmail.com>

Hi Chris,

On Thu, Oct 27, 2011 at 7:43 PM, Chris Jerdonek
<chris.jerdonek at gmail.com> wrote:
> Hi, I have one more question for the time being. ?This regards how the
> easy_install script works.
>
> I use Mac OSX, and my /usr/bin directory contains three versions of
> the easy_install script: easy_install, easy_install-2.5, and
> easy_install-2.6.
>
> Based on some debugging lines I tried inserting, when I execute the
> script called simply "easy_install", the script seems to execute just
> the first line (namely "#!/usr/bin/python"), and then seems to
> immediately jump to executing easy_install-2.6.
>
> I was curious about the mechanism that allows the Python interpreter
> to jump mysteriously from one file to another. ?This doesn't seem to
> be evident from the easy_install scripts themselves. ?What causes this
> behavior?

It appears to be this way, because your /usr/bin/python points to python2.6.
$ ls -l `which python`
lrwxrwxrwx 1 root root 9 2011-09-09 20:29 /usr/bin/python -> python2.6*

you can verify that no jumping occurs by printing a unique string in each of
 `which easy_install` `which easy_install-2.6` `which easy_install-2.5`

--
Paul Ivanov
314 address only used for lists, ?off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

From chris.jerdonek at gmail.com  Fri Oct 28 08:41:58 2011
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Thu, 27 Oct 2011 23:41:58 -0700
Subject: [Distutils] easy_install execution question
In-Reply-To: <CAKCGbV4u_2mE3TTa6TLAGj+WB5pM1fT0gKtiywin9XZXMnfPKw@mail.gmail.com>
References: <CAOTb1wfCN2AgbeS-Qv9EbqOBTR=8bTDH5b_yKw_vAGr9mqd8mg@mail.gmail.com>
	<CAKCGbV4u_2mE3TTa6TLAGj+WB5pM1fT0gKtiywin9XZXMnfPKw@mail.gmail.com>
Message-ID: <CAOTb1we2J_iue9XLGm=OQ1=kZ5UE9aK+kfWSxW1YJJrYm1aOXw@mail.gmail.com>

On Thu, Oct 27, 2011 at 10:54 PM, Paul Ivanov <pivanov314 at gmail.com> wrote:
> On Thu, Oct 27, 2011 at 7:43 PM, Chris Jerdonek
> <chris.jerdonek at gmail.com> wrote:
>>
>> Based on some debugging lines I tried inserting, when I execute the
>> script called simply "easy_install", the script seems to execute just
>> the first line (namely "#!/usr/bin/python"), and then seems to
>> immediately jump to executing easy_install-2.6.
>>
> you can verify that no jumping occurs by printing a unique string in each of
> ?`which easy_install` `which easy_install-2.6` `which easy_install-2.5`

That's what I did to observe the behavior:

If I insert "echo AAA" at the beginning of /usr/bin/easy_install,
running easy_install displays "AAA" as the first line of output.

However, when I remove "echo AAA" from the beginning of easy_install
and insert an exit statement right after the first line--

#!/usr/bin/python
exit('BBB')

as well as an exit statement right after the first line of
easy_install-2.5 (I meant to say 2.5 before)--

#!/System/Library/.../Python
print 'CCC'

running easy_install displays "CCC" rather than "BBB".  So the
interpreter seems to have jumped from the first line of easy_install
to the beginning of easy_install-2.5 -- without executing the second
line of easy_install.

--Chris

From nad at acm.org  Fri Oct 28 08:54:51 2011
From: nad at acm.org (Ned Deily)
Date: Thu, 27 Oct 2011 23:54:51 -0700
Subject: [Distutils] question re: easy_install and macports
References: <CAOTb1wf9JpwBTxqwmF8GHMC1v3vmHmkDeO7REjeOysnxy_p7-g@mail.gmail.com>
	<nad-5382F4.13233527102011@dough.gmane.org>
	<CAOTb1wdpG748xRui0CS5jP-LUgr_B1apggGy_FJMr+ZdhR0xUQ@mail.gmail.com>
Message-ID: <nad-226413.23545127102011@news.gmane.org>

In article 
<CAOTb1wdpG748xRui0CS5jP-LUgr_B1apggGy_FJMr+ZdhR0xUQ at mail.gmail.com>,
 Chris Jerdonek <chris.jerdonek at gmail.com> wrote:

> On Thu, Oct 27, 2011 at 1:23 PM, Ned Deily <nad at acm.org> wrote:
> > In article
> > <CAOTb1wf9JpwBTxqwmF8GHMC1v3vmHmkDeO7REjeOysnxy_p7-g at mail.gmail.com>,
> > ?Chris Jerdonek <chris.jerdonek at gmail.com> wrote:
> >> Hi, I have a quick question regarding easy_install and MacPorts. ?I
> >> tried easy_installing nose
> 
> >> This worked, except it installed the nosetests script into--
> >>
> >> /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin
> >>
> >> but did not create an alias in--
> >>
> >> /opt/local/bin
> >>
> > For Mac OS X Python framework builds, the easiest general solution is to
> > add the framework bin directory to your shell PATH. ?The python.org
> > installers do that by default. ?For a Macports Python, you can add
> > something like:
> >
> > export
> > PATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin:$PAT
> > H
> 
> Thanks for the reply, Ned.  Will this approach cause problems, though,
> when switching to a different Python using "port select python" --
> what's the best way to handle that issue?  Also, is there any reason
> why "port select python" wasn't written to swap out and add the
> appropriate framework bin to your PATH, say, immediately after
> /opt/local/bin?

Dunno.  You could file an issue with the MacPorts project.  It seems 
like they've added explicit links to /opt/local/bin for most of the 
ports that include Python scripts.  But that doesn't help if you are 
using easy_install or pip to install other Python packages.  For 
supporting switching between MacPorts Python versions, you can 
substitute "Current" for "2.6" in the above path; I believe "port select 
python" updates the "Current" link to point to the selected version.

-- 
 Ned Deily,
 nad at acm.org


From nad at acm.org  Fri Oct 28 09:09:24 2011
From: nad at acm.org (Ned Deily)
Date: Fri, 28 Oct 2011 00:09:24 -0700
Subject: [Distutils] easy_install execution question
References: <CAOTb1wfCN2AgbeS-Qv9EbqOBTR=8bTDH5b_yKw_vAGr9mqd8mg@mail.gmail.com>
	<CAKCGbV4u_2mE3TTa6TLAGj+WB5pM1fT0gKtiywin9XZXMnfPKw@mail.gmail.com>
Message-ID: <nad-2D7274.00092428102011@news.gmane.org>

In article 
<CAKCGbV4u_2mE3TTa6TLAGj+WB5pM1fT0gKtiywin9XZXMnfPKw at mail.gmail.com>,
 Paul Ivanov <pivanov314 at gmail.com> wrote:

> Hi Chris,
> 
> On Thu, Oct 27, 2011 at 7:43 PM, Chris Jerdonek
> <chris.jerdonek at gmail.com> wrote:
> > Hi, I have one more question for the time being. ?This regards how the
> > easy_install script works.
> >
> > I use Mac OSX, and my /usr/bin directory contains three versions of
> > the easy_install script: easy_install, easy_install-2.5, and
> > easy_install-2.6.
> >
> > Based on some debugging lines I tried inserting, when I execute the
> > script called simply "easy_install", the script seems to execute just
> > the first line (namely "#!/usr/bin/python"), and then seems to
> > immediately jump to executing easy_install-2.6.
> >
> > I was curious about the mechanism that allows the Python interpreter
> > to jump mysteriously from one file to another. ?This doesn't seem to
> > be evident from the easy_install scripts themselves. ?What causes this
> > behavior?
> 
> It appears to be this way, because your /usr/bin/python points to python2.6.
> $ ls -l `which python`
> lrwxrwxrwx 1 root root 9 2011-09-09 20:29 /usr/bin/python -> python2.6*
> 
> you can verify that no jumping occurs by printing a unique string in each of
>  `which easy_install` `which easy_install-2.6` `which easy_install-2.5`

Actually, it doesn't work that way on recent releases of Mac OS X.  
Apple implemented its own modifications to both Python and easy_install 
(setuptools) to support multiple versions; it does not use symlinks 
(unlike the MacPorts "port select" mechanism).   Rather, /usr/bin/python 
is a special wrapper executable and /usr/bin/easy_install a wrapper 
script that support persistently setting the default version in a plist 
via the defaults(1) command and/or temporarily changing the default via 
environment variable settings.  The mechanism is documented in the Apple 
man page for python.  Since neither /usr/bin/python nor 
/usr/bin/easy_install are symlinks, it's really important not to 
overwrite them.

-- 
 Ned Deily,
 nad at acm.org


From h.goebel at goebel-consult.de  Fri Oct 28 10:16:50 2011
From: h.goebel at goebel-consult.de (Hartmut Goebel)
Date: Fri, 28 Oct 2011 10:16:50 +0200
Subject: [Distutils] Status of distutils & Co.?
Message-ID: <4EAA64F2.1050408@goebel-consult.de>

Hi,

while lurking on this lists for quite some month, I'm still wondering 
about the status of all the different distutils tools, including 
setuptool, pkg_resources, pip, ...). To my impression, there are some 
efforts around, but I'm missing some kind of overview or strategy. 
Beside the forest of tools, it seams to me, as if the distribution 
format is not "stable": pip seams to prefer archives over eggs.

Is there some PEP describing the status and future of Python packaging?

-- 
Sch?nen Gru? - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP

Goebel Consult
Spezialist f?r IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de

Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult ist Mitglied bei http://www.7-it.de


From merwok at netwok.org  Fri Oct 28 18:22:25 2011
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 28 Oct 2011 18:22:25 +0200
Subject: [Distutils] Status of distutils & Co.?
In-Reply-To: <4EAA64F2.1050408@goebel-consult.de>
References: <4EAA64F2.1050408@goebel-consult.de>
Message-ID: <4EAAD6C1.3030207@netwok.org>

Hi Hartmut,

> while lurking on this lists for quite some month, I'm still wondering 
> about the status of all the different distutils tools, including 
> setuptool, pkg_resources, pip, ...). To my impression, there are some 
> efforts around, but I'm missing some kind of overview or strategy.
We don?t have a PEP but there is information out there:
-
https://tarekziade.wordpress.com/2010/03/03/the-fate-of-distutils-pycon-summit-packaging-sprint-detailed-report/
-
http://stackoverflow.com/questions/6344076/differences-between-distribute-distutils-and-setuptools

In short:
- distutils deprecated
- distribute deprecated
- distutils2 implements new standards (PEPs) and is recommended
- transition period expected, compatibility layer in distutils2

> Beside the forest of tools, it seams to me, as if the distribution 
> format is not "stable": pip seams to prefer archives over eggs.

Different formats work for different people.  Setuptools invented eggs,
which are not supported by newer tools like pip and distutils2.  Windows
users tend to prefer clicky installers anyway.  There?s a long
discussion in progress on python-dev about a kind of binary distribution
that can be supported by distutils2 (and pip when it moves from
setuptools to d2 as underlying library).

Cheers

From chris.jerdonek at gmail.com  Fri Oct 28 23:45:16 2011
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Fri, 28 Oct 2011 14:45:16 -0700
Subject: [Distutils] question re: easy_install and macports
In-Reply-To: <nad-226413.23545127102011@news.gmane.org>
References: <CAOTb1wf9JpwBTxqwmF8GHMC1v3vmHmkDeO7REjeOysnxy_p7-g@mail.gmail.com>
	<nad-5382F4.13233527102011@dough.gmane.org>
	<CAOTb1wdpG748xRui0CS5jP-LUgr_B1apggGy_FJMr+ZdhR0xUQ@mail.gmail.com>
	<nad-226413.23545127102011@news.gmane.org>
Message-ID: <CAOTb1wc54V2mkC1K+3GBL-S_qeaXTvm8DfxBfUaeJAEGXStRSg@mail.gmail.com>

On Thu, Oct 27, 2011 at 11:54 PM, Ned Deily <nad at acm.org> wrote:
>> >> Hi, I have a quick question regarding easy_install and MacPorts. ?I
>> >> tried easy_installing nose
>>
>> >> This worked, except it installed the nosetests script into--
>> >>
>> >> /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin
>> >>
>> >> but did not create an alias in--
>> >>
>> >> /opt/local/bin
>> >>
>> > For Mac OS X Python framework builds, the easiest general solution is to
>> > add the framework bin directory to your shell PATH. ?The python.org
>> > installers do that by default.
> For supporting switching between MacPorts Python versions, you can
> substitute "Current" for "2.6" in the above path; I believe "port select
> python" updates the "Current" link to point to the selected version.

Thanks.  Adding MacPorts "Current" framework bin to my path is the
solution I was looking for.

--Chris

From p.f.moore at gmail.com  Sun Oct 30 21:54:26 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 30 Oct 2011 20:54:26 +0000
Subject: [Distutils] Some distutils2/packaging questions
Message-ID: <CACac1F_UZ17QFVOB0YJr198SmmBKnNaGvSJ-eJ6JOwUPdcAzVw@mail.gmail.com>

Hi,
I hope this is the right list for usage questions on
distutils2/packaging. If not, please point me at the correct list.

I'm looking at how I'd translate existing setup.py configurations into
the new setup.cfg format. One situation I'm not sure how to deal with
is the package_data argument to setup(). This allows me to specify
data files which are to be installed as part of a package. How would I
do this in distutils2/packaging? The resources entry seems like the
intended place, but I don't see how I can specify the destination
without making too many assumptions about precisely where the package
will get installed.

Any suggestions?
Thanks,
Paul.

From andrea.crotti.0 at gmail.com  Mon Oct 31 12:49:34 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Mon, 31 Oct 2011 11:49:34 +0000
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <CALeMXf6GT9EontAfDhkTzRf9io364whwgN4yDdfZSD4iv4fiQA@mail.gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
	<4EA7DF21.3090308@gmail.com>
	<CALeMXf7Z4jchea8y-PzqK8n3jeNNCSbA-O1uOtOzfwTqQnzcBw@mail.gmail.com>
	<4EA958DB.7030003@gmail.com> <4EA975CD.3030402@gmail.com>
	<CALeMXf4C-YCcDm_qkO2GNjZ3VEFGBfDkLNWrZJixAutP=PP4jQ@mail.gmail.com>
	<4EA97F88.40908@gmail.com>
	<CALeMXf6GT9EontAfDhkTzRf9io364whwgN4yDdfZSD4iv4fiQA@mail.gmail.com>
Message-ID: <4EAE8B4E.1060607@gmail.com>

On 10/27/2011 06:17 PM, PJ Eby wrote:
> Properly reloading changed code is a lot more complex than that. 

Ah well it would be nice maybe but it's not so important, and maybe even 
Envisage can do something like that.

Anyway I was trying a simple example of using "easy_install -m", to see 
how it works.

I create a minimal library and install it with "-m", so in theory I 
thought that I can require
it and then use it and I do:
In [15]: pkg_resources.require('lib')
Out[15]: [lib 0.1 
(/home/andrea/.local/lib/python2.7/site-packages/lib-0.1-py2.7.egg)]

But then
"import lib" or "from lib import module" both fail, so am I missing 
anything else?

As you said in the other email if I have a setup.py I would not even 
that, but how do I do in practice?

I tried to do an
"easy_install --user -i . foolproof"
and foolproof actually has "lib" in install_requires.

Now "lib" is already correctly installed with the "multiversion" option, 
but then if I try to run
the script in foolproof (the installed one) I still can't import "lib".

Anything else I should do?

From andrea.crotti.0 at gmail.com  Mon Oct 31 14:45:18 2011
From: andrea.crotti.0 at gmail.com (Andrea Crotti)
Date: Mon, 31 Oct 2011 13:45:18 +0000
Subject: [Distutils] virtualenv & pypi-server
In-Reply-To: <4EAE8B4E.1060607@gmail.com>
References: <4EA689E6.4020506@gmail.com>
	<CALeMXf4an=y1Qg1iLTuojojQdhO011Z2+k-tF2=VW-eksFSmgw@mail.gmail.com>
	<4EA7DF21.3090308@gmail.com>
	<CALeMXf7Z4jchea8y-PzqK8n3jeNNCSbA-O1uOtOzfwTqQnzcBw@mail.gmail.com>
	<4EA958DB.7030003@gmail.com> <4EA975CD.3030402@gmail.com>
	<CALeMXf4C-YCcDm_qkO2GNjZ3VEFGBfDkLNWrZJixAutP=PP4jQ@mail.gmail.com>
	<4EA97F88.40908@gmail.com>
	<CALeMXf6GT9EontAfDhkTzRf9io364whwgN4yDdfZSD4iv4fiQA@mail.gmail.com>
	<4EAE8B4E.1060607@gmail.com>
Message-ID: <4EAEA66E.1040102@gmail.com>

On 10/31/2011 11:49 AM, Andrea Crotti wrote:
> On 10/27/2011 06:17 PM, PJ Eby wrote:
>> Properly reloading changed code is a lot more complex than that. 
>
> Ah well it would be nice maybe but it's not so important, and maybe 
> even Envisage can do something like that.
>
> Anyway I was trying a simple example of using "easy_install -m", to 
> see how it works.
>
> I create a minimal library and install it with "-m", so in theory I 
> thought that I can require
> it and then use it and I do:
> In [15]: pkg_resources.require('lib')
> Out[15]: [lib 0.1 
> (/home/andrea/.local/lib/python2.7/site-packages/lib-0.1-py2.7.egg)]
>
> But then
> "import lib" or "from lib import module" both fail, so am I missing 
> anything else?
>
> As you said in the other email if I have a setup.py I would not even 
> that, but how do I do in practice?
>
> I tried to do an
> "easy_install --user -i . foolproof"
> and foolproof actually has "lib" in install_requires.
>
> Now "lib" is already correctly installed with the "multiversion" 
> option, but then if I try to run
> the script in foolproof (the installed one) I still can't import "lib".
>
> Anything else I should do?

Ok after som change (not sure what) I can actually import "lib" now from 
ipython or from a script.
But importing it from the script which was built in the egg which 
actually has "lib" in install_requires
still doesn't work...

How can it be?
It doesn't add any pkg_resources trick to find the additional library, 
and in plus forcing the require doesn't work either..

From p.f.moore at gmail.com  Mon Oct 31 21:42:52 2011
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 31 Oct 2011 20:42:52 +0000
Subject: [Distutils] Odd limitation in packaging/distutils2
Message-ID: <CACac1F-66-RPrWS9_nKq4mcag=KFVg+skYhy0tFACHDdfQBM2g@mail.gmail.com>

This seems odd...

PS D:\Data\PyPI> D:\Data\cpython\PCbuild\python -m packaging.run install nose
installing third-party projects from an uninstalled Python is not supported

And yet after downloading the nose source...

PS D:\Data\PyPI> bsdtar xzf D:\Downloads\Python\nose-1.1.2.tar.gz
PS D:\Data\PyPI> cd .\nose-1.1.2
PS D:\Data\PyPI\nose-1.1.2> D:\Data\cpython\PCbuild\python -m
packaging.run install
Installing from source directory: 'D:\\Data\\PyPI\\nose-1.1.2'
Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.14.tar.gz
Extracting in c:\users\gustav\appdata\local\temp\tmpecso_w
Now working in c:\users\gustav\appdata\local\temp\tmpecso_w\distribute-0.6.14
Building a Distribute egg in D:\Data\PyPI\nose-1.1.2
warning: no files found matching 'Makefile' under directory 'docs'
warning: no files found matching 'indexsidebar.html' under directory 'docs'
creating build
creating build\src
... etc

(The build actually failed, but for reasons unrelated to the fact that
it's an uninstalled Python, as far as I can see).

Why not allow installing direct from PyPI?

Paul.