From vinay_sajip at yahoo.co.uk  Tue May  1 12:59:25 2012
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Tue, 1 May 2012 10:59:25 +0000 (UTC)
Subject: [Distutils]
	=?utf-8?q?command=5Fhooks_and_Python-3=2E3=2E0a3=3F?=
	=?utf-8?b?Pz8=?=
References: <CAAq8ydvqi9YbHzs4hnGMO1DNDyb1PVrFC5GTTpYB-Hg01QWo2w@mail.gmail.com>
	<4F96B7EE.7060707@netwok.org>
Message-ID: <loom.20120501T125406-624@post.gmane.org>

?ric Araujo <merwok <at> netwok.org> writes:

> before; I don?t know if the scripts generation feature (something like 
> setuptools? console_scripts/gui_scripts entry points) will be ready in 
> time.

I have a working (though not comprehensively tested) implementation of script
generation in the pythonv branch (I've referred to it in the relevant Python
issue). I believe you had some GSoC work done on this last year, but I'm not
sure what the status of that is; I could help bring this into packaging, if it's
OK with you. It would be a shame if it were left out of 3.3 for lack of
time/resource. I'm quite comfortable in both POSIX and Windows, and I think
consideration of both environments is needed for the script generation, because
of e.g. executable launchers being needed on Windows (at least, currently).

Regards,

Vinay Sajip


From vinay_sajip at yahoo.co.uk  Tue May  1 13:19:14 2012
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Tue, 1 May 2012 11:19:14 +0000 (UTC)
Subject: [Distutils] PEP 405 (Python Virtual Environments) - some input
	needed
Message-ID: <loom.20120501T130804-987@post.gmane.org>

As we get ever closer to the Python 3.3 beta, we need to ensure that all the
functionality we'd like to see in 3.3 is ready for inclusion.

One set of functionality is built-in virtual environments, as proposed by PEP
405 (Python Virtual Environments). There's a reference implementation [1], which
seems to work pretty well; but the PEP has some open issues which someone on
this list may be able to comment on. I'm particularly interested to hear what
functionality is needed in the area of include files for C extensions. If you
could look at the open issue on this [2] and give some feedback, that would be
great. If you have the time to check out the reference implementation as a
whole, then general comments on that would also be much appreciated - for
example, it contains (though not part of PEP 405) packaging-related
enhancements, e.g. code to handle extensible categories for setup.cfg
(http://bugs.python.org/issue12393) and script generation
(http://bugs.python.org/issue12394).

Thanks and regards,

Vinay Sajip

[1] https://bitbucket.org/vinay.sajip/pythonv/
[2] http://www.python.org/dev/peps/pep-0405/#what-about-include-files


From chrism at plope.com  Tue May  1 18:40:23 2012
From: chrism at plope.com (Chris McDonough)
Date: Tue, 01 May 2012 12:40:23 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4F924AEC.9030501@netwok.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org>
Message-ID: <4FA011F7.3010701@plope.com>

On 04/21/2012 01:51 AM, ?ric Araujo wrote:
> Hi again,
>
>> Is Distutils2 kind of your baby?  Simply, you are the only one working
>> on it!
> It?s more like my foster kid.  At first there was distutils, in the
> standard library since 1999.  After a few years it stopped being
> actively developed, and people started to rely on undocumented behavior
> and internal things.  Four years ago Tarek Ziad? became the new
> maintainer for distutils and attacked the big pile of bugs and feature
> requests.  He hit a barrier when his changes broke other people?s code,
> so it was decided two years ago to stop adding new features or clean up
> code in distutils and instead start anew in a project named distutils2,
> where backward compatibility would not stall all improvement efforts.
> That?s when I started contributing, as a Google Summer of Code student
> and then a volunteer.  Tarek focused on distutils2 and passed on the
> maintenance of distutils to me, and later I also became the maintainer
> of distutils2, i.e. I reply to most bugs and make the releases.  Tarek
> is still the lead of the project and weighs in for important changes.

Georg Brandl was trying to herd cats on outstanding PEPs today:

http://mail.python.org/pipermail/python-dev/2012-May/119157.html

Is there a PEP for the "packaging" package?  Is there any sort of 
unfinished business I can help with?

- C


>
>> I am curious as to what you mean by this statement, when I get
>> some spare round tuits?
> That?s a wordplay from the expression ?I?ll get around to it? ? ?I?ll
> get a round tuit?.
>
>>  From the bug tracker page, this has been around for over a year!
> Bugs live from a few minutes to a few years; with more than 300 bugs on
> my list, I can?t get to everything at the same time.  For the last
> months I?ve also been busy with paperwork and a new job.  But be sure
> the bug is not forgotten; it?s one of the things that will be fixed
> before distutils2 1.0 and Python 3.3.0.
>
>> I applied the diff file that was attached to the page to the current
>> Python-3.3.0a2, and it doesn't make a bit of difference on the
>> outcome...
> If you read the full bug report you?ll see that this patch was already
> applied and only fixes setup hooks; I said that I was working on a patch
> for commands hooks but I did not upload it as it was not finished.
>
>> I also added the path to sys.path, like this:
>> sys.path.append(os.getcwd()) and it doesn't make a difference!
> Probably because you did that in your code, but that makes no difference
> because it happens after pysetup is started and tries to import your
> module.  I don?t know if I?ll have time to fix this bug tomorrow, as
> I?ll have mentoring to do, so no promises here.
>
>> After the upcoming Distutils2 sprint, when will the work be patched
>> into Distutils2?  When will we see the benefit of all the work that
>> will be done???
> The changes from the sprint will go into the main repository
> immediately, and after a short while they will get ported into packaging
> in the cpython repository.  I want to release distutils2 1.0a5 soon
> after the sprint.
>
>> 1) http://dl.dropbox.com/u/47247655/create_setup_cfg.py
>> [...]
>> 1) Will create the setup.cfg file if one is not there...?
> As you?re using open('setup.cfg', 'w'), the file will be recreated each
> time you run the script.  I?m not sure you need that script; why not
> just create the config file once and keep it updated when you have changes?
>
> Regards
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


From p.f.moore at gmail.com  Tue May  1 20:28:07 2012
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 1 May 2012 19:28:07 +0100
Subject: [Distutils] command hooks...
In-Reply-To: <4FA011F7.3010701@plope.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
Message-ID: <CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>

On 1 May 2012 17:40, Chris McDonough <chrism at plope.com> wrote:
> Georg Brandl was trying to herd cats on outstanding PEPs today:
>
> http://mail.python.org/pipermail/python-dev/2012-May/119157.html
>
> Is there a PEP for the "packaging" package? ?Is there any sort of unfinished
> business I can help with?

AFAIK, there's no specific PEP for packaging (there are a number of
related PEPs, but nothing specific like a roadmap).

I'm sure ?ric can give you much better pointers on what would be
useful, but one issue I've tried to raise a few times, and more
recently Jim Fulton raised here
(http://mail.python.org/pipermail/distutils-sig/2012-March/018323.html)
is that of binary distribution support in packaging2. I've never had
the time to shepherd a proposal through beyond the "initial debate"
stage, and I know it's not getting high on ?ric's list of priorities,
but it would be good to see some movement on this.

I can offer opinions, Windows testing, and assistance, but I really
don't have the time to make this happen. But I honestly believe that
unless packaging has binary distribution support, it won't get
"critical mass", on Windows if nowhere else.

Just a thought - if it's where your interests lie, that would be great.
Paul.

From chrism at plope.com  Tue May  1 20:38:23 2012
From: chrism at plope.com (Chris McDonough)
Date: Tue, 01 May 2012 14:38:23 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
Message-ID: <4FA02D9F.2060000@plope.com>

On 05/01/2012 02:28 PM, Paul Moore wrote:
> On 1 May 2012 17:40, Chris McDonough<chrism at plope.com>  wrote:
>> Georg Brandl was trying to herd cats on outstanding PEPs today:
>>
>> http://mail.python.org/pipermail/python-dev/2012-May/119157.html
>>
>> Is there a PEP for the "packaging" package?  Is there any sort of unfinished
>> business I can help with?
>
> AFAIK, there's no specific PEP for packaging (there are a number of
> related PEPs, but nothing specific like a roadmap).
>
> I'm sure ?ric can give you much better pointers on what would be
> useful, but one issue I've tried to raise a few times, and more
> recently Jim Fulton raised here
> (http://mail.python.org/pipermail/distutils-sig/2012-March/018323.html)
> is that of binary distribution support in packaging2. I've never had
> the time to shepherd a proposal through beyond the "initial debate"
> stage, and I know it's not getting high on ?ric's list of priorities,
> but it would be good to see some movement on this.
>
> I can offer opinions, Windows testing, and assistance, but I really
> don't have the time to make this happen. But I honestly believe that
> unless packaging has binary distribution support, it won't get
> "critical mass", on Windows if nowhere else.

Yeah, it's kinda required.  We currently tell people to avoid pip 
because it doesn't support installation of binary distributions.  It's 
just too hard to document the corner cases of using both pip and 
easy_install at the same time, or telling Windows people to use 
easy_install and UNIX people to use pip, or some combination thereof.

I'm not sure if other features we (the Pylons project) make heavy use of 
like extras, console scripts, entry points, and testing hooks are 
currently supported, but if they aren't I'd be willing to help add them 
as necessary.  We wouldn't really be able to use it without this stuff, 
in any case.

> Just a thought - if it's where your interests lie, that would be great.
> Paul.

In a perfect world, I'd not be volunteering, but it looks like I have to 
if I want to be able to get to bitch. ;-)

- C

From rbpark at gmail.com  Thu May  3 09:13:32 2012
From: rbpark at gmail.com (Robert Park)
Date: Thu, 3 May 2012 02:13:32 -0500
Subject: [Distutils] Confounded by unhelpful error message.
Message-ID: <CAL3PwKxwz9HVZbMrEdy2NWA34WbmmRRg_wdodoo6Roo=F3arpg@mail.gmail.com>

So, I'm using distutils to build RPMs on Fedora. I've had success with
this in the past but now I'm running into a problem and I'm not sure
how to fix it since the error message is an outright lie!

I start like this, naturally:

$ python setup.py bdist_rpm
running bdist_rpm
writing 'build/bdist.linux-x86_64/rpm/SPECS/GottenGeography.spec'
running sdist
running check
warning: sdist: standard file not found: should have one of README, README.txt

reading manifest template 'MANIFEST.in'
not writing to manually maintained manifest file 'MANIFEST'
creating GottenGeography-1.0.1
creating GottenGeography-1.0.1/data
creating GottenGeography-1.0.1/gg
creating GottenGeography-1.0.1/po
making hard links in GottenGeography-1.0.1...
hard linking README.md -> GottenGeography-1.0.1
[.... blah blah blah ....]
Creating tar archive
removing 'GottenGeography-1.0.1' (and everything under it)
copying dist/GottenGeography-1.0.1.tar.gz ->
build/bdist.linux-x86_64/rpm/SOURCES
building RPMs
rpm: build/bdist.linux-x86_64/rpm/SPECS/GottenGeography.spec: No such
file or directory
error: Failed to execute: "rpm -q --qf
'%{name}-%{version}-%{release}.src.rpm
%{arch}/%{name}-%{version}-%{release}.%{arch}.rpm\\n' --specfile
'build/bdist.linux-x86_64/rpm/SPECS/GottenGeography.spec'"


And it just stops right there. Note that the very second line of
output indicates that it is creating this file. Indeed:

$ ls -lh build/bdist.linux-x86_64/rpm/SPECS/GottenGeography.spec
-rw-r--r--. 1 robru robru 1.3K May  3 02:04
build/bdist.linux-x86_64/rpm/SPECS/GottenGeography.spec

The file is there, with exactly the indicated path.

What is going wrong here? Google has turned up nothing, although it is
admittedly very difficult to search for since "No such file or
directory" is a very common error message and there's not a lot else
to go on here.

The only thing I can think of is that there's a distutils dependency
that I don't have installed, as this computer is a fresh install since
the last time this worked for me. But rpm and distutils are both
installed so I'm not really sure what exactly could be missing.

Help? Thanks.

-- 
http://exolucere.ca

From robhealey1 at gmail.com  Tue May  8 23:51:22 2012
From: robhealey1 at gmail.com (Rob Healey)
Date: Tue, 8 May 2012 14:51:22 -0700
Subject: [Distutils] command hooks
Message-ID: <CAAq8ydspPt74pr4HG=xRVp245Yw=W1-txvMAwVVyZ49AfkMvgA@mail.gmail.com>

Greetings:

I looked all around the bug tracker to try to add a comment and a thank you
for providing it, but I could not even find a login button or if I were
even logged in...

My issues that I was having regarding the command hooks is now fixed and
working perfectly for me!  I am so excited and grateful for this patch...

One of the developers had made some incredible changes, but I was not able
to even run them as I was plagued by this bug until now...  Do you know
when it will be committed into the DistUtils2-1.0 code base?

I am running Fedora Core rawhide/Fc18.x86_64, and it works wonderful for
me...

-- 
Sincerely yours,
Rob G. Healey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120508/b32f848b/attachment.html>

From info at rickvanderzwet.nl  Thu May 10 00:42:07 2012
From: info at rickvanderzwet.nl (Rick van der Zwet)
Date: Thu, 10 May 2012 00:42:07 +0200
Subject: [Distutils] easy_install runnable in a sandbox environment?
Message-ID: <CAAN28g2eOc_P=B==ND8n4k39iJewg5qOEP8ymkbMojyM03SzYw@mail.gmail.com>

I am having issues in running easy_install in a sandbox environment
(chroot with python2.7 under FreeBSD 9.0-RELASE, without /dev mount).
easy_install is sourcing tempfile, which requires /dev/urandom to be
present, as seen in the backtrace:

    brahm# sh -x setuptools-0.6c11-py2.7.egg
    + basename setuptools-0.6c11-py2.7.egg
    + [ setuptools-0.6c11-py2.7.egg = setuptools-0.6c11-py2.7.egg ]
    + exec python2.7 -c 'import sys, os; sys.path.insert(0,
os.path.abspath('\''setuptools-0.6c11-py2.7.egg'\'')); from
setuptools.command.easy_install import bootstrap;
sys.exit(bootstrap())'
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/usr/local/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/easy_install.py",
line 12, in <module>
      File "/usr/local/lib/python2.7/tempfile.py", line 34, in <module>
        from random import Random as _Random
      File "/usr/local/lib/python2.7/random.py", line 881, in <module>
        _inst = Random()
      File "/usr/local/lib/python2.7/random.py", line 97, in __init__
        self.seed(x)
      File "/usr/local/lib/python2.7/random.py", line 111, in seed
        a = long(_hexlify(_urandom(16)), 16)
    OSError: [Errno 2] No such file or directory: '/dev/urandom'

Quite some time ago, their has been comments in the changelog (06.c4)
stating that running easy_install without /dev/urandom should be
possible:
   Fixed not allowing os.open() of paths outside the sandbox, even if
they are opened read-only (e.g. reading /dev/urandom for random
numbers, as is done by os.urandom() on some platforms).

While this was back in 2006, I was wondering what the current state of
affairs which regards of requiring the /dev/urandom as of today? Am I
looking at a  feature request, bug report or design limitation?

Br. /Rick
-- 
http://rickvanderzwet.nl

From merwok at netwok.org  Thu May 10 01:13:04 2012
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 09 May 2012 19:13:04 -0400
Subject: [Distutils] command hooks
In-Reply-To: <CAAq8ydspPt74pr4HG=xRVp245Yw=W1-txvMAwVVyZ49AfkMvgA@mail.gmail.com>
References: <CAAq8ydspPt74pr4HG=xRVp245Yw=W1-txvMAwVVyZ49AfkMvgA@mail.gmail.com>
Message-ID: <4FAAFA00.6080806@netwok.org>

Hi Rob,

> I looked all around the bug tracker to try to add a comment and a thank you
> for providing it, but I could not even find a login button or if I were
> even logged in...
You can log in with the small form in the sidebar on the left.  When you 
are logged in, a bug page appears as an HTML form instead of just text.

> My issues that I was having regarding the command hooks is now fixed and
> working perfectly for me!  I am so excited and grateful for this patch...
>
> One of the developers had made some incredible changes, but I was not able
> to even run them as I was plagued by this bug until now...  Do you know
> when it will be committed into the DistUtils2-1.0 code base?
I don?t know what you are talking about :)  You had a problem, found a 
patch (for distutils2?) and it fixed it?

Cheers

From merwok at netwok.org  Thu May 10 01:20:40 2012
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 09 May 2012 19:20:40 -0400
Subject: [Distutils] Distutils2 Sprint in Montreal
Message-ID: <4FAAFBC8.9040204@netwok.org>

   Hi all,

   The Montreal-Python user group is organizing a second sprint to work 
on distutils2 on May 12th.  If you live in Montreal, take a laptop and 
come join us!  No previous knowledge of Distutils2 is required, just 
general Python skills.  All details are found here:

   http://montrealpython.org/2012/05/distutils2-sprint-2/

   Cheers

From pje at telecommunity.com  Thu May 10 05:30:25 2012
From: pje at telecommunity.com (PJ Eby)
Date: Wed, 9 May 2012 23:30:25 -0400
Subject: [Distutils] easy_install runnable in a sandbox environment?
In-Reply-To: <CAAN28g2eOc_P=B==ND8n4k39iJewg5qOEP8ymkbMojyM03SzYw@mail.gmail.com>
References: <CAAN28g2eOc_P=B==ND8n4k39iJewg5qOEP8ymkbMojyM03SzYw@mail.gmail.com>
Message-ID: <CALeMXf6sJzT2RSfPoaCSJY2WhMGDoD7+vuu1PgCTFDM0VicSmg@mail.gmail.com>

On Wed, May 9, 2012 at 6:42 PM, Rick van der Zwet <info at rickvanderzwet.nl>wrote:

> Quite some time ago, their has been comments in the changelog (06.c4)
> stating that running easy_install without /dev/urandom should be
> possible:
>   Fixed not allowing os.open() of paths outside the sandbox, even if
> they are opened read-only (e.g. reading /dev/urandom for random
> numbers, as is done by os.urandom() on some platforms).
>
> While this was back in 2006, I was wondering what the current state of
> affairs which regards of requiring the /dev/urandom as of today? Am I
> looking at a  feature request, bug report or design limitation?
>

You're confusing easy_install's internal sandboxing with running
easy_install in a chroot environment.  easy_install runs setup scripts in a
Python sandbox that disallows certain file accesses in order to handle
badly-coded setup.py files that copy files directly to guessed installation
locations, instead of relying on the distutils to do the copying.  The
change notes you're reading are discussing *that* sandbox, which is
internal to Python/setuptools and is unrelated to chrooting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120509/3b85e2d9/attachment.html>

From info at rickvanderzwet.nl  Thu May 10 19:25:17 2012
From: info at rickvanderzwet.nl (Rick van der Zwet)
Date: Thu, 10 May 2012 19:25:17 +0200
Subject: [Distutils] easy_install runnable in a sandbox environment?
In-Reply-To: <CALeMXf6sJzT2RSfPoaCSJY2WhMGDoD7+vuu1PgCTFDM0VicSmg@mail.gmail.com>
References: <CAAN28g2eOc_P=B==ND8n4k39iJewg5qOEP8ymkbMojyM03SzYw@mail.gmail.com>
	<CALeMXf6sJzT2RSfPoaCSJY2WhMGDoD7+vuu1PgCTFDM0VicSmg@mail.gmail.com>
Message-ID: <CAAN28g3QfFiZS-7Pj_mR4o+USfEcfuzLW1Ny6F8yLhowN=HO5g@mail.gmail.com>

On 10 May 2012 05:30, PJ Eby <pje at telecommunity.com> wrote:
> On Wed, May 9, 2012 at 6:42 PM, Rick van der Zwet <info at rickvanderzwet.nl>
> wrote:
>>
>> Quite some time ago, their has been comments in the changelog (06.c4)
>> stating that running easy_install without /dev/urandom should be
>> possible:
>> ? Fixed not allowing os.open() of paths outside the sandbox, even if
>> they are opened read-only (e.g. reading /dev/urandom for random
>> numbers, as is done by os.urandom() on some platforms).
>>
>> While this was back in 2006, I was wondering what the current state of
>> affairs which regards of requiring the /dev/urandom as of today? Am I
>> looking at a ?feature request, bug report or design limitation?
>
>
> You're confusing easy_install's internal sandboxing with running
> easy_install in a chroot environment.? easy_install runs setup scripts in a
> Python sandbox that disallows certain file accesses in order to handle
> badly-coded setup.py files that copy files directly to guessed installation
> locations, instead of relying on the distutils to do the copying.? The
> change notes you're reading are discussing *that* sandbox, which is internal
> to Python/setuptools and is unrelated to chrooting.

Spot on, nice! Mounting /dev (mount -t devfs devfs
/usr/local/sandbox/dev) before entering the sandbox will be the
solution then.

Thanks for explaining.
/Rick
-- 
http://rickvanderzwet.nl

From rbpark at gmail.com  Fri May 11 19:52:42 2012
From: rbpark at gmail.com (Robert Park)
Date: Fri, 11 May 2012 12:52:42 -0500
Subject: [Distutils] [SOLVED] Confounded by unhelpful error message.
In-Reply-To: <CAL3PwKxwz9HVZbMrEdy2NWA34WbmmRRg_wdodoo6Roo=F3arpg@mail.gmail.com>
References: <CAL3PwKxwz9HVZbMrEdy2NWA34WbmmRRg_wdodoo6Roo=F3arpg@mail.gmail.com>
Message-ID: <CAL3PwKzBntDR3dkk7rd7mr_jKXWZS7TT00twdU=XDyR8FebupQ@mail.gmail.com>

Naturally I'd forgotten to install the rpm-build package, this solves
everything.

I'm still shaking my head at that *awful* error message though.

On Thu, May 3, 2012 at 2:13 AM, Robert Park <rbpark at gmail.com> wrote:
> building RPMs
> rpm: build/bdist.linux-x86_64/rpm/SPECS/GottenGeography.spec: No such file or directory
> error: Failed to execute: "rpm -q --qf
> '%{name}-%{version}-%{release}.src.rpm
> %{arch}/%{name}-%{version}-%{release}.%{arch}.rpm\\n' --specfile
> 'build/bdist.linux-x86_64/rpm/SPECS/GottenGeography.spec'"

-- 
http://exolucere.ca

From chris.jerdonek at gmail.com  Fri May 11 20:36:13 2012
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Fri, 11 May 2012 11:36:13 -0700
Subject: [Distutils] two setup scripts
Message-ID: <CAOTb1we979SVxhTwFK_dc+=hp2Ltk7aHvLjHtWiM65LFTWzFPQ@mail.gmail.com>

I have an open-ended question about the idea of creating two setup
scripts for a project: one for end-users (e.g. installing), and
another for all other use cases (e.g. project development).

Here are a few reasons I came across for considering something like this:

The first is that if the project needs to support, say, Python 2.4
through Python 3.2, then having two setup scripts would let you
require (and develop against) Python 2.7 for the developer version,
while supporting all versions only for the simpler end-user version.
This would also let you do things like import from the project itself
in the developer version of your setup script, a process that would
break if running the setup script using Python 3 (assuming you are
using 2to3 for Python 3 support).

The second is that I have a pre-processing step that requires using
pandoc to generate setup()'s long_description from README and HISTORY
files in markdown format prior to uploading to PyPI, and I don't want
end-users to need pandoc.  I am currently dealing with this in code,
but it would be nicer to have simpler code with fewer "if blocks."

The third is simply separation of concerns.

This approach raises the following questions:

(1) Which setup commands should each version of the script support?

(2) Which arguments to setup() are required and/or used for each command?

I would also like to know (2) independent of creating two setup
scripts.  For example, I mentioned long_description above.  The
long_description seems to be available in places like PKG-INFO and in
the DOAP xml file exposed on PyPI, so is it necessary to pass
long_description, etc to setup() for any setup command other than
sdist (which creates PKG-INFO), or is it also necessary to pass that
metadata to setup() even with the upload and install commands?

Thanks,
--Chris

From merwok at netwok.org  Fri May 11 20:58:23 2012
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 11 May 2012 14:58:23 -0400
Subject: [Distutils] [SOLVED] Confounded by unhelpful error message.
In-Reply-To: <CAL3PwKzBntDR3dkk7rd7mr_jKXWZS7TT00twdU=XDyR8FebupQ@mail.gmail.com>
References: <CAL3PwKxwz9HVZbMrEdy2NWA34WbmmRRg_wdodoo6Roo=F3arpg@mail.gmail.com>
	<CAL3PwKzBntDR3dkk7rd7mr_jKXWZS7TT00twdU=XDyR8FebupQ@mail.gmail.com>
Message-ID: <4FAD614F.5030804@netwok.org>

Hi,

Le 11/05/2012 13:52, Robert Park a ?crit :
> Naturally I'd forgotten to install the rpm-build package, this solves
> everything.

Thank you for sending the answer, this can be helpful for other people.

I thought about suggesting you were maybe missing rpm or rpmbuild, but 
decided not to send that thought because you had said ?rpm and distutils 
are both installed?.  I never really looked into the bdist_rpm code, and 
I have no idea of how rpm works.  I should learn a bit more when I find 
time to work on http://bugs.python.org/issue11122

> I'm still shaking my head at that *awful* error message though.

Yep, lying about the file that?s missing is definitely not good.  I?ll 
investigate distutils.spawn to see if I can fix that.

Cheers

From rbpark at exolucere.ca  Sat May 12 09:48:18 2012
From: rbpark at exolucere.ca (Robert Park)
Date: Sat, 12 May 2012 02:48:18 -0500
Subject: [Distutils] [SOLVED] Confounded by unhelpful error message.
In-Reply-To: <4FAD614F.5030804@netwok.org>
References: <CAL3PwKxwz9HVZbMrEdy2NWA34WbmmRRg_wdodoo6Roo=F3arpg@mail.gmail.com>
	<CAL3PwKzBntDR3dkk7rd7mr_jKXWZS7TT00twdU=XDyR8FebupQ@mail.gmail.com>
	<4FAD614F.5030804@netwok.org>
Message-ID: <CAL3PwKyHNi=hXBn6y97wspmhFCAkv1=Uh+_Eip34ez+KfPhf0Q@mail.gmail.com>

On Fri, May 11, 2012 at 1:58 PM, ?ric Araujo <merwok at netwok.org> wrote:
> Thank you for sending the answer, this can be helpful for other people.

I seem to run into this problem every year when I upgrade my system
and have to reinstall all my dev tools, so I must admit my message was
quite selfish, hoping that I would find it the next time I go googling
for this error.

> I thought about suggesting you were maybe missing rpm or rpmbuild, but
> decided not to send that thought because you had said ?rpm and distutils are
> both installed?.

Yeah, I was being quite specific. I had installed the package called
'rpm'. It hadn't occurred to me that there was another package that
was required.

> I never really looked into the bdist_rpm code, and I have
> no idea of how rpm works. ?I should learn a bit more when I find time to
> work on http://bugs.python.org/issue11122

It seems like more of a Fedora/redhat bug:

https://bugzilla.redhat.com/show_bug.cgi?id=697435

>> I'm still shaking my head at that *awful* error message though.
>
> Yep, lying about the file that?s missing is definitely not good. ?I?ll
> investigate distutils.spawn to see if I can fix that.

Cool, thanks.

-- 
http://exolucere.ca

From rbpark at exolucere.ca  Sat May 12 10:58:38 2012
From: rbpark at exolucere.ca (Robert Park)
Date: Sat, 12 May 2012 03:58:38 -0500
Subject: [Distutils] Need some advice on extending install_data
Message-ID: <CAL3PwKz78A60jN9ecHk3aUkiZ+9j2GaHTpU2x9p56M52TtgG3w@mail.gmail.com>

So, I'm using distutils with some success lately, and I've borrowed
some code that extends install_data to compile .po (translation) files
into .mo files to be used by the system to display the translated
strings. It looks like this:

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

It seems fairly straightforward to me and there's only a tiny amount
of magic involved.

However, upon testing this, I've discovered this behavior:

1. When running `setup.py install`, the mo files are correctly
compiled and installed to the system.

2. When running `setup.py bdist`, the resulting tarball will correctly
compile and include the mo files for distribution.

3. When running `setup.py bdist_rpm`, the resulting RPM file does not
contain any trace of any .po or .mo files.

I'm not sure why bdist_rpm is the odd man out here, but it seems like
I'm overlooking something simple. Unfortunately the API reference
seems a little light on details:

http://docs.python.org/distutils/apiref.html#module-distutils.command.bdist

So I'm not entirely clear on how I should go about overriding
bdist_rpm to achieve the same thing as is done by overriding
install_data. At this point I am reviewing the distutils source code
directly but it's been less instructive than I'd hoped.

Any ideas?

Thanks.

-- 
http://exolucere.ca

From rbpark at exolucere.ca  Sat May 12 22:16:59 2012
From: rbpark at exolucere.ca (Robert Park)
Date: Sat, 12 May 2012 15:16:59 -0500
Subject: [Distutils] Need some advice on extending install_data
In-Reply-To: <CAL3PwKz78A60jN9ecHk3aUkiZ+9j2GaHTpU2x9p56M52TtgG3w@mail.gmail.com>
References: <CAL3PwKz78A60jN9ecHk3aUkiZ+9j2GaHTpU2x9p56M52TtgG3w@mail.gmail.com>
Message-ID: <CAL3PwKx-sH=v65hxZtsHcxqE_zKr+Wdj6z6YKeV4e=mfo9TKpg@mail.gmail.com>

On Sat, May 12, 2012 at 3:58 AM, Robert Park <rbpark at exolucere.ca> wrote:
> So, I'm using distutils with some success lately, and I've borrowed
> some code that extends install_data to compile .po (translation) files
> into .mo files to be used by the system to display the translated
> strings. It looks like this:
>
> https://github.com/robru/gottengeography/blob/master/setup.py

Linking to the master blob was somewhat foolish as I've now come up
with a solution and the original email is now ambiguous. So, to
clarify, the problematic setup.py looked like this:

https://github.com/robru/gottengeography/blob/4f452871e325152a52b6b0f5831bf7661ec6077f/setup.py

My solution involved ripping out all of the install_data overrides and
just directly executing what needed to be done. I'm not sure if this
is particularly elegant or correct, but it works. I can't possibly be
the only person alive who wants to use distutils to create
internationalized/localized RPMs, so I'd appreciate the community's
input on the correctness of my solution:

https://github.com/robru/gottengeography/blob/b3588ca26041ad8da703c318eba757d111f2996d/setup.py

-- 
http://exolucere.ca

From rbpark at exolucere.ca  Sat May 12 22:31:24 2012
From: rbpark at exolucere.ca (Robert Park)
Date: Sat, 12 May 2012 15:31:24 -0500
Subject: [Distutils] [SOLVED] Confounded by unhelpful error message.
In-Reply-To: <CAL3PwKyHNi=hXBn6y97wspmhFCAkv1=Uh+_Eip34ez+KfPhf0Q@mail.gmail.com>
References: <CAL3PwKxwz9HVZbMrEdy2NWA34WbmmRRg_wdodoo6Roo=F3arpg@mail.gmail.com>
	<CAL3PwKzBntDR3dkk7rd7mr_jKXWZS7TT00twdU=XDyR8FebupQ@mail.gmail.com>
	<4FAD614F.5030804@netwok.org>
	<CAL3PwKyHNi=hXBn6y97wspmhFCAkv1=Uh+_Eip34ez+KfPhf0Q@mail.gmail.com>
Message-ID: <CAL3PwKxATC3q_tBcuYKg4Oz0ucA5e0trWZ-oszDnbf8BjeCv8w@mail.gmail.com>

On Sat, May 12, 2012 at 2:48 AM, Robert Park <rbpark at exolucere.ca> wrote:
>> Yep, lying about the file that?s missing is definitely not good. ?I?ll
>> investigate distutils.spawn to see if I can fix that.
>
> Cool, thanks.

I noticed on line 327 of bdist_rpm.py that there's actually a check
for whether it should be using 'rpm' or 'rpmbuild' commands. I wonder
if that test could be expanded to test for the case of rpmbuild not
existing but rpm command not having rpmbuild capabilities, and then
printing a more useful error message.

-- 
http://exolucere.ca

From chrism at plope.com  Sun May 13 20:45:53 2012
From: chrism at plope.com (Chris McDonough)
Date: Sun, 13 May 2012 14:45:53 -0400
Subject: [Distutils] packaging in python 3.3 (was Re:  command hooks...)
In-Reply-To: <4FA011F7.3010701@plope.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
Message-ID: <4FB00161.8030400@plope.com>

On 05/01/2012 12:40 PM, Chris McDonough wrote:
>
> Georg Brandl was trying to herd cats on outstanding PEPs today:
>
> http://mail.python.org/pipermail/python-dev/2012-May/119157.html
>
> Is there a PEP for the "packaging" package? Is there any sort of
> unfinished business I can help with?

Let's try this again.  If distutils2/packaging is meant to actually be 
part of Python 3.3, I think it needs some documentation and 
implementation loving.  Is there a list of outstanding issues that need 
resolution?  I'm willing to row on them, but I need some direction.

I can't really see packaging being included in Python 3.3 without a good 
bit of work being put into it.  Am I mistaken?

- C

From benoit at marmelune.net  Sun May 13 23:44:22 2012
From: benoit at marmelune.net (=?ISO-8859-1?Q?Beno=EEt_Bryon?=)
Date: Sun, 13 May 2012 23:44:22 +0200
Subject: [Distutils] conventions or best practice to choose package names?
Message-ID: <4FB02B36.8040504@marmelune.net>

Hi,

I am looking for a convention (i.e. kind of PEP) about package names: 
"how to choose a good package name".
I couldn't find a PEP which gives guidelines about it.

PEP 8 gives some guidelines about "syntax" of package names.
I found articles like "Rules of thumb" section of 
http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and-namespaces. 
But I was looking for something more "official".
And thus, I was thinking of a PEP, or something similar.


Scope:

* we have tools to create and distribute packages. Not covered by this 
thread.
* we have tools to create namespace packages. Not covered by this thread.
* we have conventions about "syntax" of module names in PEP 8. Not 
covered by this thread.
* do we have conventions, or at least guidelines, to choose a name for a 
package?


I'm not to write this guide here (I'm not an expert about it), but, if 
such a PEP or documentation doesn't exist, here are some considerations 
to start:

* The Zen of Python tells "There should be one-- and preferably only one 
--obvious way to do it."
* 
http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and-namespaces 
seems interesting
* maybe 
http://guide.python-distribute.org/specification.html#naming-specification 
is a cool place
* maybe http://docs.python.org/dev/packaging/ is the right place for 
that kind of information
* We should cover both simple packages and namespace packages.
* I guess some teams or communities already have such conventions. As an 
example, does the Plone community have one?
* I feel there are too much de facto standards on Pypi: as an example 
Plone community uses namespaces like "plone.app.theming", whereas Django 
community uses "django-*" pattern, there are also many "pyramid_*" 
packages...
* We should cover public packages published on Pypi, but also public 
packages published on online repositories like Github, and also private 
(personal or corporate) packages.
* I know we cannot migrate existing package names.
* We could recommend something for new packages.


Here are quotes seen in a recent thread about PEP 420 
(http://mail.python.org/pipermail/import-sig/2012-May/000631.html), 
which make me believe a convention would be useful.
Notice that, in fact, I discovered PEP 420 while searching for a PEP 
about "how to choose a good namespace".


Le 13/05/2012 19:25, PJ Eby a ?crit :
> Regarding the nesting issue and persuading Django developers to use 
> namespaces, I would note that there isn't any reason for namespaces to 
> be deeply nested in the first place.  By convention, top-level 
> namespace packages should be the name of a project or its sponsoring 
> organization, which means there is rarely a need for deep nesting.  
> Even cases like zope.app and peak.util are rare: usually a project or 
> organization will have only one such "miscellaneous" namespace with 
> lots of separately-distibuted components.
>
> (After all, the main reason to *have* a namespace package is to have 
> separately-distributed subpackages.  So, self-contained packages don't 
> need to have namespaces of their own, almost by definition.)
>
> Anyway, what I've noticed is that when people want to deeply nest 
> namespaces, it's usually because they're trying to share a namespace 
> across organizations, like making a shared 'net.*' namespace.  The 
> idea of namespaces isn't for that kind of categorization, though, it's 
> for *ownership*.  If two developers are fighting over where to put 
> something in a category hierarchy, it's a sign that they need to be 
> working in different namespaces, with each developer staking a claim 
> to a *top-level* package -- like OSAF's osaf.*, Zope Corporation's 
> zc.* (vs. the community project's zope.*), and so on.
>
> When developers use namespaces for project/ownership distinction, the 
> resulting package hierarchies can be pretty much as flat as you like.

If I had to explain it to another Python developer, I wish I could give 
him an hyperlink and say "read and follow the convention".


Le 13/05/2012 20:56, "Martin v. L?wis" a ?crit :
> In Java, people apparently want that because they get these deeply
> nested directory hiearchies (org/apache/commons/betwixt/expression).
> It's apparently possible to condense this into
> org.apache.commons.betwixt/expression (which isn't a shorter string,
> but fewer cd commands / explorer clicks / .svn folders).
>
> I predict that people will start using PEP 420 in the reversed-domain 
> fashion also, so we eventually might end up wanting something like 
> this for Python.

Could we anticipate namespace usage? At least for some "simple" things 
that already are de facto standards.
As an example, I guess we could state about "reasonable maximum 
namespace depth", because on Pypi there is not many packages with more 
than 3 levels.


Regards,
Benoit


From robhealey1 at gmail.com  Mon May 14 08:50:57 2012
From: robhealey1 at gmail.com (Rob Healey)
Date: Sun, 13 May 2012 23:50:57 -0700
Subject: [Distutils] May 12th sprint???
Message-ID: <CAAq8yds0SR5-qhrq+Tokn0tyW7oXQ8QtbCq232jOQkTHmvhtJA@mail.gmail.com>

Greetings:

How well do you think that the sprint worked???  Was all was accomplished?

-- 
Sincerely yours,
Rob G. Healey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120513/9c59d52c/attachment.html>

From jim at zope.com  Mon May 14 13:12:56 2012
From: jim at zope.com (Jim Fulton)
Date: Mon, 14 May 2012 07:12:56 -0400
Subject: [Distutils] conventions or best practice to choose package
	names?
In-Reply-To: <4FB02B36.8040504@marmelune.net>
References: <4FB02B36.8040504@marmelune.net>
Message-ID: <CAPDm-FgW_QjVWV30SdYTvnXZzCeDYg=vTpwVjVsBKraVjZeEiw@mail.gmail.com>

On Sun, May 13, 2012 at 5:44 PM, Beno?t Bryon <benoit at marmelune.net> wrote:

...

> Le 13/05/2012 19:25, PJ Eby a ?crit :
>>
>> Regarding the nesting issue and persuading Django developers to use
>> namespaces, I would note that there isn't any reason for namespaces to be
>> deeply nested in the first place. ?By convention, top-level namespace
>> packages should be the name of a project or its sponsoring organization,
>> which means there is rarely a need for deep nesting. ?Even cases like
>> zope.app and peak.util are rare: usually a project or organization will have
>> only one such "miscellaneous" namespace with lots of separately-distibuted
>> components.
>>
>> (After all, the main reason to *have* a namespace package is to have
>> separately-distributed subpackages. ?So, self-contained packages don't need
>> to have namespaces of their own, almost by definition.)
>>
>> Anyway, what I've noticed is that when people want to deeply nest
>> namespaces, it's usually because they're trying to share a namespace across
>> organizations, like making a shared 'net.*' namespace. ?The idea of
>> namespaces isn't for that kind of categorization, though, it's for
>> *ownership*. ?If two developers are fighting over where to put something in
>> a category hierarchy, it's a sign that they need to be working in different
>> namespaces, with each developer staking a claim to a *top-level* package --
>> like OSAF's osaf.*, Zope Corporation's zc.* (vs. the community project's
>> zope.*), and so on.
>>
>> When developers use namespaces for project/ownership distinction, the
>> resulting package hierarchies can be pretty much as flat as you like.

Well said.  IMO, only one level of nesting is necessary.  When I've
used nested namespaces in the past, it was out of a compulsion to
over-organize. :)

But:

> Le 13/05/2012 20:56, "Martin v. L?wis" a ?crit :
>>
>> In Java, people apparently want that because they get these deeply
>> nested directory hiearchies (org/apache/commons/betwixt/expression).
>> It's apparently possible to condense this into
>> org.apache.commons.betwixt/expression (which isn't a shorter string,
>> but fewer cd commands / explorer clicks / .svn folders).
>>
>> I predict that people will start using PEP 420 in the reversed-domain
>> fashion also, so we eventually might end up wanting something like this for
>> Python.

If Python were more popular, I think we'd be more like Java in this
regard.

When I create a package like ``zc.thread`` it allows me to use a
package named ``thread`` without being presumptuous and trying to
claim a top-level name like "thread". But "zc" is a little
presumptuous too.  Might there someday be another organization who's
initials are "zc"?

Lately, I've gotten the impression that people are rejecting the use
of namespace packages altogether. There's an incorrect notion that
namespace packages are an invention of setuptools.  I think this is
unfortunate.

+1 for an official document (or addition to an existinhg document)
   providing a rational for namespace packages and their naming.

Jim

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

From martin at v.loewis.de  Mon May 14 14:02:52 2012
From: martin at v.loewis.de (martin at v.loewis.de)
Date: Mon, 14 May 2012 14:02:52 +0200
Subject: [Distutils] conventions or best practice to choose package
 names?
In-Reply-To: <CAPDm-FgW_QjVWV30SdYTvnXZzCeDYg=vTpwVjVsBKraVjZeEiw@mail.gmail.com>
References: <4FB02B36.8040504@marmelune.net>
	<CAPDm-FgW_QjVWV30SdYTvnXZzCeDYg=vTpwVjVsBKraVjZeEiw@mail.gmail.com>
Message-ID: <20120514140252.Horde.sj4xXFNNcXdPsPRsWfU317A@webmail.df.eu>

> Lately, I've gotten the impression that people are rejecting the use
> of namespace packages altogether. There's an incorrect notion that
> namespace packages are an invention of setuptools.  I think this is
> unfortunate.

Indeed, it's unfortunate. It took me some time to discover that (presumably)
the original idea was first formulated in

https://mail.zope.org/pipermail/zope3-dev/2002-December/004251.html

I'd be curious to know whether there is an even earlier (public) discussion
of namespace packages.

Regards,
Martin



From rbpark at exolucere.ca  Tue May 15 08:33:56 2012
From: rbpark at exolucere.ca (Robert Park)
Date: Tue, 15 May 2012 01:33:56 -0500
Subject: [Distutils] Questions about install-prefix in distutils.
Message-ID: <CAL3PwKxxNQbEE-YqQJ9ynDvMnV-2vwySXhZfKY6WeCF4f4=gwA@mail.gmail.com>

Hello,

I found this email from some years ago:

http://mail.python.org/pipermail/distutils-sig/2009-September/013284.html

I find myself now having the same problems. My lazy solution so far
has been to simply install the data files into the same module
directory, and then I just do os.path.join(os.path.dirname(__file__),
'datafile.txt') when I want to access a data file.

This was ok when I only had one data file, but my project is expanding
and I need something more robust and organized. I tried to look at
other projects similar to mine to see how they handled this situation,
and it turns out that none of them use distutils! They are all using
autotools, and while that's a very cumbersome set of tools, it allows
them to pre-process the source files so that the source files know
where they've been installed to in a very straightforward way.

So I'm just wondering, is this build_py override still the best way to
accomplish this? Has this functionality been rolled into distutils in
the last 3 years? How are folks handling this situation now-a-days?

Note that I don't use setuptools so I'm looking for a pure-distutils solution.

Thanks!

-- 
http://exolucere.ca

From merwok at netwok.org  Tue May 15 17:54:01 2012
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 15 May 2012 11:54:01 -0400
Subject: [Distutils] May 12th sprint???
In-Reply-To: <CAAq8yds0SR5-qhrq+Tokn0tyW7oXQ8QtbCq232jOQkTHmvhtJA@mail.gmail.com>
References: <CAAq8yds0SR5-qhrq+Tokn0tyW7oXQ8QtbCq232jOQkTHmvhtJA@mail.gmail.com>
Message-ID: <4FB27C19.1090707@netwok.org>

Hi Rob,

> How well do you think that the sprint worked???  Was all was
> accomplished?

The sprint went well!  We were not many but this allowed me to be more 
available when needed and we fixed six bugs.  In absolute numbers this 
is not much, but the important part is that more people are able and 
willing to work on the codebase.  We?ll try to squeeze two more sprints 
before the beta deadline and this time I?ll put features on the list; 
they should take more time than just bugs but be more gratifying to work on.

I don?t post sprint wrap-ups on this mailing list but on 
montrealpython.org (and not immediately after an event :), feel free to 
follow there.

Cheers

From merwok at netwok.org  Tue May 15 18:01:23 2012
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 15 May 2012 12:01:23 -0400
Subject: [Distutils] command_hooks and Python-3.3.0a3???
In-Reply-To: <loom.20120501T125406-624@post.gmane.org>
References: <CAAq8ydvqi9YbHzs4hnGMO1DNDyb1PVrFC5GTTpYB-Hg01QWo2w@mail.gmail.com>
	<4F96B7EE.7060707@netwok.org>
	<loom.20120501T125406-624@post.gmane.org>
Message-ID: <4FB27DD3.2000400@netwok.org>

Hi,

Le 01/05/2012 06:59, Vinay Sajip a ?crit :
> I have a working (though not comprehensively tested) implementation of script
> generation in the pythonv branch (I've referred to it in the relevant Python
> issue). I believe you had some GSoC work done on this last year, but I'm not
> sure what the status of that is; I could help bring this into packaging, if it's
> OK with you. It would be a shame if it were left out of 3.3 for lack of
> time/resource. I'm quite comfortable in both POSIX and Windows, and I think
> consideration of both environments is needed for the script generation, because
> of e.g. executable launchers being needed on Windows (at least, currently).

I know you can help on some important issues and I will certainly ask 
you specific questions to move them to completion.  First I need to 
generate a refreshed patch and review it, then we will work together to 
have this committed in time.

Cheers

From tarek at ziade.org  Tue May 15 18:02:09 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 15 May 2012 18:02:09 +0200
Subject: [Distutils] packaging in python 3.3 (was Re: command hooks...)
In-Reply-To: <4FB00161.8030400@plope.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<4FB00161.8030400@plope.com>
Message-ID: <4FB27E01.6050301@ziade.org>

On 5/13/12 8:45 PM, Chris McDonough wrote:
> On 05/01/2012 12:40 PM, Chris McDonough wrote:
>>
>> Georg Brandl was trying to herd cats on outstanding PEPs today:
>>
>> http://mail.python.org/pipermail/python-dev/2012-May/119157.html
>>
>> Is there a PEP for the "packaging" package? Is there any sort of
>> unfinished business I can help with?
>
> Let's try this again.  If distutils2/packaging is meant to actually be 
> part of Python 3.3, I think it needs some documentation and 
> implementation loving.  Is there a list of outstanding issues that 
> need resolution?  I'm willing to row on them, but I need some direction.
>
> I can't really see packaging being included in Python 3.3 without a 
> good bit of work being put into it.  Am I mistaken?

No you're not, we're quite late on what we need to finish -- I am unable 
to spend time on this these days, I defer directions to Eric.

Maybe we could organize regular sprints to try to finish this



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


From merwok at netwok.org  Tue May 15 18:07:19 2012
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 15 May 2012 12:07:19 -0400
Subject: [Distutils] packaging in python 3.3 (was Re: command hooks...)
In-Reply-To: <4FB00161.8030400@plope.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<4FB00161.8030400@plope.com>
Message-ID: <4FB27F37.5030802@netwok.org>

Hi,

Le 13/05/2012 14:45, Chris McDonough a ?crit :
> Let's try this again.  If distutils2/packaging is meant to actually be
> part of Python 3.3, I think it needs some documentation and
> implementation loving.  Is there a list of outstanding issues that need
> resolution?  I'm willing to row on them, but I need some direction.
For the doc I?ve been working on a big patch to cover the change from 
setup.py to setup.cfg and pysetup.  Otherwise there are many things that 
could be improved, like the tutorial or a cookbook, but patches for this 
can go after the beta or even final release.  There is a list of issues 
on bugs.python.org (search for the distutils2 component), but I did not 
prioritize it.

> I can't really see packaging being included in Python 3.3 without a good
> bit of work being put into it.  Am I mistaken?
A good bit of work was put into it, not the least to convert it to 
Python 3 (and then back to Python 2), but not all is done.  In the worst 
case packaging 1.0 in Python 3.3 will work for simple cases and people 
will be able to use it to install a newer version of distutils2.  I 
still think it?s possible to do better than this worst case.

Going to reply to your other message now.

Regards

From merwok at netwok.org  Tue May 15 22:39:04 2012
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 15 May 2012 16:39:04 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
Message-ID: <4FB2BEE8.9030908@netwok.org>

Hi again,

Le 01/05/2012 14:28, Paul Moore a ?crit :
> On 1 May 2012 17:40, Chris McDonough<chrism at plope.com>  wrote:
>> Is there a PEP for the "packaging" package?  Is there any sort of unfinished
>> business I can help with?
> AFAIK, there's no specific PEP for packaging (there are a number of
> related PEPs, but nothing specific like a roadmap).
Yep.  distutils2/packaging implement PEP 345 (Metadata 1.2), 376 
(dist-info directory a.k.a. installation database) and 386 (version 
numbers), and also the older Metadata PEPs like distutils, but there was 
no PEP to discuss inclusion of d2 in Python 3.3: it just happened when a 
core developer (Martin von L?wis) indicated he was opposed to work on 
features (to add support for PEP 384 ? Stable ABI for example) outside 
of the Python repository.  I think that no PEP was asked by anyone 
because distutils2 is forked from code already in the stdlib and it 
implements accepted PEPs.  There are small and big features added or in 
progress, many of them inspired by setuptools, that don?t have a PEP though.

As I said on my other reply there is no friendly list of issues or 
roadmap, only unsorted bugs and what?s in my mind.

> I'm sure ?ric can give you much better pointers on what would be
> useful, but one issue I've tried to raise a few times, and more
> recently Jim Fulton raised here
> (http://mail.python.org/pipermail/distutils-sig/2012-March/018323.html)
> is that of binary distribution support in packaging2. I've never had
> the time to shepherd a proposal through beyond the "initial debate"
> stage, and I know it's not getting high on ?ric's list of priorities,
> but it would be good to see some movement on this.
Indeed, in private email with Paul I agreed on the importance of a 
binary distribution format and did a pre-publication review of his PEP, 
but we did not finish our discussion nor incorporated the alternate 
proposal that was discussed at PyCon and on the mailing list (which 
makes it hard to see a clear picture ? PEPs are good :)

It seems unlikely that this hard topic can be solved for Python 3.3 / 
distutils2 1.0; what can be done however is to make sure that the 
extensibility hooks in d2 are well tested and documented so that when a 
bdist PEP reaches agreement and is implemented, a simple pysetup call 
and two lines of config will be all it takes to be able to use the new 
command.

I know that the situation is far from ideal, and far from our goals for 
3.3, but anyway d2 was never intended as a full replacement for 
setuptools and pip (more on that in an upcoming reply to another of your 
messages when you listed the setuptools features used by Pyramid).  I 
think packaging in Python 3.3 will be a first version put in the stdlib 
to gather feedback and reports, not a finished stable product.

Regards

From arty.net2 at gmail.com  Wed May 16 01:01:03 2012
From: arty.net2 at gmail.com (Arturo Rinaldi)
Date: Wed, 16 May 2012 01:01:03 +0200
Subject: [Distutils] total uninstall of setuptool on MacOS X by consequence
 of manual install
Message-ID: <4FB2E02F.2070602@gmail.com>

I installed some time ago on MacOS X Lion the python-setuptools script 
with the shell command

*/$ sudo sh setuptools-0.6c11-py2.7.egg/*

then I uninstalled any .egg installed and removed the script itself with

/*$ sudo easy_install -m setuptools*

/which in turn removed the /easy_install.pth /file//in the 
//Library/Python/2.7/site-packages// directory. Now by running the 
command /ls/ in that directory i get :

*/README
setuptools.pth
vboxapi-1.0-py2.7.egg-info
setuptools-0.6c11-py2.7.egg
vboxapi//*

can i remove /setuptools.pth and //setuptools-0.6c11-py2.7.egg /too ? 
I'd like also to perform a total clean uninstallation so i searched in 
my HD and i found that i still have the files :

*//usr/bin/easy_install
/usr/bin/easy_install-2.5
/usr/bin/easy_install-2.6
/usr/bin/easy_install-2.7 /*

and the following directories (i attach the output in a text file). I 
also installed python-numpy through it and then uninstalled the package 
itself in the standard way.

Which directories and files can i delete without harming my system (so i 
can totally switch to macports) ? Thx in advance.

Regards, Arturo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120516/0e47746d/attachment-0001.html>
-------------- next part --------------
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/__init__.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/__init__.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/archive_util.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/archive_util.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/cli.exe
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/__init__.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/__init__.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/alias.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/alias.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/bdist_egg.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/bdist_egg.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/bdist_rpm.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/bdist_rpm.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/bdist_wininst.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/bdist_wininst.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/build_ext.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/build_ext.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/build_py.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/build_py.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/develop.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/develop.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/easy_install.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/easy_install.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/egg_info.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/egg_info.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/install.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/install.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/install_egg_info.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/install_egg_info.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/install_lib.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/install_lib.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/install_scripts.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/install_scripts.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/register.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/register.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/rotate.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/rotate.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/saveopts.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/saveopts.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/sdist.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/sdist.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/setopt.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/setopt.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/test.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/test.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/upload.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/command/upload.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/depends.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/depends.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/dist.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/dist.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/extension.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/extension.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/gui.exe
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/package_index.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/package_index.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/sandbox.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/sandbox.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/tests
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/tests/__init__.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/tests/__init__.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/tests/doctest.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/tests/doctest.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/tests/test_packageindex.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/tests/test_packageindex.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/tests/test_resources.py
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools/tests/test_resources.pyc
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools-0.6c9-py2.5.egg-info
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools-0.6c9-py2.5.egg-info/PKG-INFO
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools-0.6c9-py2.5.egg-info/SOURCES.txt
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools-0.6c9-py2.5.egg-info/dependency_links.txt
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools-0.6c9-py2.5.egg-info/entry_points.txt
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools-0.6c9-py2.5.egg-info/top_level.txt
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/setuptools-0.6c9-py2.5.egg-info/zip-safe
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/__init__.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/__init__.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/archive_util.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/archive_util.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/cli.exe
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/__init__.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/__init__.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/alias.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/alias.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/bdist_egg.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/bdist_egg.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/bdist_rpm.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/bdist_rpm.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/bdist_wininst.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/bdist_wininst.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/build_ext.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/build_ext.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/build_py.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/build_py.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/develop.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/develop.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/easy_install.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/easy_install.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/egg_info.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/egg_info.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/install.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/install.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/install_egg_info.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/install_egg_info.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/install_lib.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/install_lib.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/install_scripts.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/install_scripts.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/register.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/register.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/rotate.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/rotate.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/saveopts.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/saveopts.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/sdist.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/sdist.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/setopt.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/setopt.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/test.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/test.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/upload.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/upload.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/depends.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/depends.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/dist.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/dist.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/extension.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/extension.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/gui.exe
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/package_index.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/package_index.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/sandbox.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/sandbox.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/tests
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/tests/__init__.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/tests/__init__.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/tests/doctest.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/tests/doctest.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/tests/test_packageindex.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/tests/test_packageindex.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/tests/test_resources.py
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/tests/test_resources.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.6.egg-info
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.6.egg-info/PKG-INFO
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.6.egg-info/SOURCES.txt
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.6.egg-info/dependency_links.txt
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.6.egg-info/entry_points.txt
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.6.egg-info/top_level.txt
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.6.egg-info/zip-safe
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/tests/setuptools_build_ext.py
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/tests/setuptools_build_ext.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/tests/setuptools_build_ext.pyo
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/tests/setuptools_extension.py
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/tests/setuptools_extension.pyc
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/distutils/tests/setuptools_extension.pyo
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/__init__.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/__init__.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/archive_util.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/archive_util.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/cli.exe
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/__init__.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/__init__.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/alias.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/alias.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/bdist_egg.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/bdist_egg.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/bdist_rpm.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/bdist_rpm.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/bdist_wininst.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/bdist_wininst.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/build_ext.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/build_ext.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/build_py.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/build_py.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/develop.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/develop.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/easy_install.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/easy_install.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/egg_info.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/egg_info.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/install.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/install.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/install_egg_info.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/install_egg_info.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/install_lib.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/install_lib.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/install_scripts.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/install_scripts.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/register.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/register.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/rotate.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/rotate.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/saveopts.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/saveopts.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/sdist.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/sdist.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/setopt.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/setopt.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/test.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/test.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/upload.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/command/upload.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/depends.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/depends.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/dist.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/dist.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/extension.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/extension.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/gui.exe
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/package_index.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/package_index.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/sandbox.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/sandbox.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/tests
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/tests/__init__.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/tests/__init__.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/tests/doctest.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/tests/doctest.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/tests/test_packageindex.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/tests/test_packageindex.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/tests/test_resources.py
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/tests/test_resources.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.7.egg-info
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.7.egg-info/PKG-INFO
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.7.egg-info/SOURCES.txt
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.7.egg-info/dependency_links.txt
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.7.egg-info/entry_points.txt
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.7.egg-info/top_level.txt
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools-0.6c12dev_r85381-py2.7.egg-info/zip-safe
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/tests/setuptools_build_ext.py
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/tests/setuptools_build_ext.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/tests/setuptools_build_ext.pyo
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/tests/setuptools_extension.py
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/tests/setuptools_extension.pyc
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/tests/setuptools_extension.pyo

From nad at acm.org  Wed May 16 02:35:59 2012
From: nad at acm.org (Ned Deily)
Date: Tue, 15 May 2012 17:35:59 -0700
Subject: [Distutils] total uninstall of setuptool on MacOS X by
	consequence of manual install
References: <4FB2E02F.2070602@gmail.com>
Message-ID: <nad-E48324.17355915052012@news.gmane.org>

In article <4FB2E02F.2070602 at gmail.com>,
 Arturo Rinaldi <arty.net2 at gmail.com> wrote:

> can i remove /setuptools.pth and //setuptools-0.6c11-py2.7.egg /too ? 
> I'd like also to perform a total clean uninstallation so i searched in 
> my HD and i found that i still have the files :
> 
> *//usr/bin/easy_install
> /usr/bin/easy_install-2.5
> /usr/bin/easy_install-2.6
> /usr/bin/easy_install-2.7 /*
> 
> and the following directories (i attach the output in a text file). I 
> also installed python-numpy through it and then uninstalled the package 
> itself in the standard way.
> 
> Which directories and files can i delete without harming my system (so i 
> can totally switch to macports) ? Thx in advance.

Those easy_installs are shipped by Apple as part of OS X and they apply 
to the Apple-supplied system Pythons.  You should not attempt to remove 
them.  If you are installing a MacPort Python, you need to install the 
corresponding MacPorts easy_install port, currently provided by 
pyxx-distribute and ensure you are using it instead of one of the system 
ones (and assuming MacPorts doesn't already provide a port of the 
third-party Python package you want to use).  A very simplified example 
of what you'd need for the a default install of the latest MacPorts 
Python 2.7:

$ sudo /opt/local/bin/port selfupdate
$ sudo /opt/local/bin/port install py27-distribute
$ sudo /opt/local/bin/port select --set python python27
$ export 
PATH=/opt/local/Library/Frameworks/Python.framework/Versions/Current/bin:
/opt/local/bin:$PATH
$ which easy_install-2.7
/opt/local/Library/Frameworks/Python.framework/Versions/Current/bin/easy_
install-2.7

-- 
 Ned Deily,
 nad at acm.org


From arty.net2 at gmail.com  Wed May 16 02:55:05 2012
From: arty.net2 at gmail.com (Arturo Rinaldi)
Date: Wed, 16 May 2012 02:55:05 +0200
Subject: [Distutils] total uninstall of setuptool on MacOS X by
 consequence of manual install
In-Reply-To: <nad-E48324.17355915052012@news.gmane.org>
References: <4FB2E02F.2070602@gmail.com>
	<nad-E48324.17355915052012@news.gmane.org>
Message-ID: <4FB2FAE9.7020901@gmail.com>

Nella citazione in data Wed May 16 02:35:59 2012, Ned Deily ha scritto:
> In article<4FB2E02F.2070602 at gmail.com>,
>   Arturo Rinaldi<arty.net2 at gmail.com>  wrote:
>
>> can i remove /setuptools.pth and //setuptools-0.6c11-py2.7.egg /too ?
>> I'd like also to perform a total clean uninstallation so i searched in
>> my HD and i found that i still have the files :
>>
>> *//usr/bin/easy_install
>> /usr/bin/easy_install-2.5
>> /usr/bin/easy_install-2.6
>> /usr/bin/easy_install-2.7 /*
>>
>> and the following directories (i attach the output in a text file). I
>> also installed python-numpy through it and then uninstalled the package
>> itself in the standard way.
>>
>> Which directories and files can i delete without harming my system (so i
>> can totally switch to macports) ? Thx in advance.
>
> Those easy_installs are shipped by Apple as part of OS X and they apply
> to the Apple-supplied system Pythons.  You should not attempt to remove
> them.  If you are installing a MacPort Python, you need to install the
> corresponding MacPorts easy_install port, currently provided by
> pyxx-distribute and ensure you are using it instead of one of the system
> ones (and assuming MacPorts doesn't already provide a port of the
> third-party Python package you want to use).  A very simplified example
> of what you'd need for the a default install of the latest MacPorts
> Python 2.7:
>
> $ sudo /opt/local/bin/port selfupdate
> $ sudo /opt/local/bin/port install py27-distribute
> $ sudo /opt/local/bin/port select --set python python27
> $ export
> PATH=/opt/local/Library/Frameworks/Python.framework/Versions/Current/bin:
> /opt/local/bin:$PATH
> $ which easy_install-2.7
> /opt/local/Library/Frameworks/Python.framework/Versions/Current/bin/easy_
> install-2.7
>

I finally see ! So these were my last steps :

$ sudo sh setuptools-0.6c11-py2.7.egg
$ sudo easy_install -m setuptools

sudo rm /Library/Python/2.7/site-packages/setuptools.pth
sudo rm /Library/Python/2.7/site-packages/setuptools-0.6c11-py2.7.egg
sudo rm /usr/local/bin/easy_install
sudo rm /usr/local/bin/easy_install-2.7

in a few words, I removed all the stuff installed in the first step 
(and that apperead in the stdout)....is it all right now ? In the 
future i will only use the python-packages built with macports (i.e. 
py27-numpy). I asked help because I was very confused with all that 
stuff....thx very much for replying me so soon.

From nad at acm.org  Wed May 16 03:24:28 2012
From: nad at acm.org (Ned Deily)
Date: Tue, 15 May 2012 18:24:28 -0700
Subject: [Distutils] total uninstall of setuptool on MacOS X by
	consequence of manual install
References: <4FB2E02F.2070602@gmail.com>
	<nad-E48324.17355915052012@news.gmane.org>
	<4FB2FAE9.7020901@gmail.com>
Message-ID: <nad-4D15E3.18242815052012@news.gmane.org>

In article <4FB2FAE9.7020901 at gmail.com>,
 Arturo Rinaldi <arty.net2 at gmail.com> wrote:
> I finally see ! So these were my last steps :
> 
> $ sudo sh setuptools-0.6c11-py2.7.egg
> $ sudo easy_install -m setuptools
> 
> sudo rm /Library/Python/2.7/site-packages/setuptools.pth
> sudo rm /Library/Python/2.7/site-packages/setuptools-0.6c11-py2.7.egg
> sudo rm /usr/local/bin/easy_install
> sudo rm /usr/local/bin/easy_install-2.7
> 
> in a few words, I removed all the stuff installed in the first step 
> (and that apperead in the stdout)....is it all right now ? In the 
> future i will only use the python-packages built with macports (i.e. 
> py27-numpy). I asked help because I was very confused with all that 
> stuff....thx very much for replying me so soon.

Well, removing those files won't hurt but, if you set your PATH as 
suggested, it shouldn't make any difference either.  The MacPorts files 
are installed in a completely separate location and one of the 
advantages of OS X Python framework installs is that multiple versions 
can co-exist on the same system without interfering with each other.

-- 
 Ned Deily,
 nad at acm.org


From chrism at plope.com  Wed May 16 03:58:11 2012
From: chrism at plope.com (Chris McDonough)
Date: Tue, 15 May 2012 21:58:11 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FB2BEE8.9030908@netwok.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org>
Message-ID: <4FB309B3.5060406@plope.com>

On 05/15/2012 04:39 PM, ?ric Araujo wrote:
> Hi again,
>
> Le 01/05/2012 14:28, Paul Moore a ?crit :
>> On 1 May 2012 17:40, Chris McDonough<chrism at plope.com> wrote:
>>> Is there a PEP for the "packaging" package? Is there any sort of
>>> unfinished
>>> business I can help with?
>> AFAIK, there's no specific PEP for packaging (there are a number of
>> related PEPs, but nothing specific like a roadmap).
> Yep. distutils2/packaging implement PEP 345 (Metadata 1.2), 376
> (dist-info directory a.k.a. installation database) and 386 (version
> numbers), and also the older Metadata PEPs like distutils, but there was
> no PEP to discuss inclusion of d2 in Python 3.3: it just happened when a
> core developer (Martin von L?wis) indicated he was opposed to work on
> features (to add support for PEP 384 ? Stable ABI for example) outside
> of the Python repository. I think that no PEP was asked by anyone
> because distutils2 is forked from code already in the stdlib and it
> implements accepted PEPs. There are small and big features added or in
> progress, many of them inspired by setuptools, that don?t have a PEP
> though.
>
> As I said on my other reply there is no friendly list of issues or
> roadmap, only unsorted bugs and what?s in my mind.

OK.  Is there a way for me to take a look at the unsorted bugs?

>> I'm sure ?ric can give you much better pointers on what would be
>> useful, but one issue I've tried to raise a few times, and more
>> recently Jim Fulton raised here
>> (http://mail.python.org/pipermail/distutils-sig/2012-March/018323.html)
>> is that of binary distribution support in packaging2. I've never had
>> the time to shepherd a proposal through beyond the "initial debate"
>> stage, and I know it's not getting high on ?ric's list of priorities,
>> but it would be good to see some movement on this.
> Indeed, in private email with Paul I agreed on the importance of a
> binary distribution format and did a pre-publication review of his PEP,
> but we did not finish our discussion nor incorporated the alternate
> proposal that was discussed at PyCon and on the mailing list (which
> makes it hard to see a clear picture ? PEPs are good :)
>
> It seems unlikely that this hard topic can be solved for Python 3.3 /
> distutils2 1.0; what can be done however is to make sure that the
> extensibility hooks in d2 are well tested and documented so that when a
> bdist PEP reaches agreement and is implemented, a simple pysetup call
> and two lines of config will be all it takes to be able to use the new
> command.
>
> I know that the situation is far from ideal, and far from our goals for
> 3.3, but anyway d2 was never intended as a full replacement for
> setuptools and pip (more on that in an upcoming reply to another of your
> messages when you listed the setuptools features used by Pyramid). I
> think packaging in Python 3.3 will be a first version put in the stdlib
> to gather feedback and reports, not a finished stable product.

I really don't want to add stop energy here, and I'm more than willing 
to row to get something going, but I'm afraid if that's the diagnosis, 
it means I'll personally have to oppose the inclusion of packaging in 
3.3.  We currently already have at least 3 competing solutions 
(setuptools, distribute, and distutils itself), and people are baffled 
about which to use and how to use it.  Adding two more (packaging and 
distutils2) which are similarly semi-documented and which don't even 
solve the problems that the previous ones do would serve no purpose, and 
baking them into Python itself will mean they can't evolve in important 
ways.   I'd suggest we just put the brakes on and slate something better 
for 3.4.  Does that make sense, or does that make people sad?

- C

From aclark at aclark.net  Wed May 16 05:01:41 2012
From: aclark at aclark.net (Alex Clark)
Date: Tue, 15 May 2012 23:01:41 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FB309B3.5060406@plope.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
Message-ID: <jov5am$kh4$1@dough.gmane.org>

Hi,

On 5/15/12 9:58 PM, Chris McDonough wrote:
> On 05/15/2012 04:39 PM, ?ric Araujo wrote:
>> Hi again,
>>
>> Le 01/05/2012 14:28, Paul Moore a ?crit :
>>> On 1 May 2012 17:40, Chris McDonough<chrism at plope.com> wrote:
>>>> Is there a PEP for the "packaging" package? Is there any sort of
>>>> unfinished
>>>> business I can help with?
>>> AFAIK, there's no specific PEP for packaging (there are a number of
>>> related PEPs, but nothing specific like a roadmap).
>> Yep. distutils2/packaging implement PEP 345 (Metadata 1.2), 376
>> (dist-info directory a.k.a. installation database) and 386 (version
>> numbers), and also the older Metadata PEPs like distutils, but there was
>> no PEP to discuss inclusion of d2 in Python 3.3: it just happened when a
>> core developer (Martin von L?wis) indicated he was opposed to work on
>> features (to add support for PEP 384 ? Stable ABI for example) outside
>> of the Python repository. I think that no PEP was asked by anyone
>> because distutils2 is forked from code already in the stdlib and it
>> implements accepted PEPs. There are small and big features added or in
>> progress, many of them inspired by setuptools, that don?t have a PEP
>> though.
>>
>> As I said on my other reply there is no friendly list of issues or
>> roadmap, only unsorted bugs and what?s in my mind.
>
> OK. Is there a way for me to take a look at the unsorted bugs?
>
>>> I'm sure ?ric can give you much better pointers on what would be
>>> useful, but one issue I've tried to raise a few times, and more
>>> recently Jim Fulton raised here
>>> (http://mail.python.org/pipermail/distutils-sig/2012-March/018323.html)
>>> is that of binary distribution support in packaging2. I've never had
>>> the time to shepherd a proposal through beyond the "initial debate"
>>> stage, and I know it's not getting high on ?ric's list of priorities,
>>> but it would be good to see some movement on this.
>> Indeed, in private email with Paul I agreed on the importance of a
>> binary distribution format and did a pre-publication review of his PEP,
>> but we did not finish our discussion nor incorporated the alternate
>> proposal that was discussed at PyCon and on the mailing list (which
>> makes it hard to see a clear picture ? PEPs are good :)
>>
>> It seems unlikely that this hard topic can be solved for Python 3.3 /
>> distutils2 1.0; what can be done however is to make sure that the
>> extensibility hooks in d2 are well tested and documented so that when a
>> bdist PEP reaches agreement and is implemented, a simple pysetup call
>> and two lines of config will be all it takes to be able to use the new
>> command.
>>
>> I know that the situation is far from ideal, and far from our goals for
>> 3.3, but anyway d2 was never intended as a full replacement for
>> setuptools and pip (more on that in an upcoming reply to another of your
>> messages when you listed the setuptools features used by Pyramid). I
>> think packaging in Python 3.3 will be a first version put in the stdlib
>> to gather feedback and reports, not a finished stable product.
>
> I really don't want to add stop energy here, and I'm more than willing
> to row to get something going, but I'm afraid if that's the diagnosis,
> it means I'll personally have to oppose the inclusion of packaging in
> 3.3. We currently already have at least 3 competing solutions
> (setuptools, distribute, and distutils itself), and people are baffled
> about which to use and how to use it. Adding two more (packaging and
> distutils2) which are similarly semi-documented and which don't even
> solve the problems that the previous ones do would serve no purpose, and
> baking them into Python itself will mean they can't evolve in important
> ways. I'd suggest we just put the brakes on and slate something better
> for 3.4. Does that make sense, or does that make people sad?


+1. I think that makes sense. I'd be willing to work on something if I 
felt like I understood what was going on, which I don't. For example, 
distribute's goal seems very clear: provide a well-maintained and 
frequently-released setuptools. It would make sense (to me) to include 
distribute in a future release of Python, to close the loop of the 
non-std-lib-packaging-lib-built-on-top-distutils-but-never-included-in-the-stdlib-situation. 
But IIUC, it's too convoluted to attempt such a thing, and 
distutils2/packaging was meant to provide us the freedom to break 
backwards compat, but to what end? I don't think I fully understand the 
over-arching, real-world practical goals are for packaging in Python 3.x 
(other than to provide the pysetup command, and ini-style configuration 
over setup.py.)


Alex


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


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


From arty.net2 at gmail.com  Wed May 16 07:46:07 2012
From: arty.net2 at gmail.com (Arturo Rinaldi)
Date: Wed, 16 May 2012 07:46:07 +0200
Subject: [Distutils] total uninstall of setuptool on MacOS X by
	consequence of manual install
In-Reply-To: <nad-4D15E3.18242815052012@news.gmane.org>
References: <4FB2E02F.2070602@gmail.com>
	<nad-E48324.17355915052012@news.gmane.org>
	<4FB2FAE9.7020901@gmail.com>
	<nad-4D15E3.18242815052012@news.gmane.org>
Message-ID: <CAFDE-S4AA8Mjr+ijzu5SOa1v9=u=2t3EqcyTgrZA+iG5Q9MkqA@mail.gmail.com>

Yes you're very right but since i Install other ports having python27 as
dependency, i usually do

sudo port select --set python python27

Doing so my default Python2.7 version becomes 2.7.3, and then I can Install
py27-numpy, py27-scipy and so on......

Arturo

Il giorno mercoled? 16 maggio 2012, Ned Deily ha scritto:

> In article <4FB2FAE9.7020901 at gmail.com <javascript:;>>,
>  Arturo Rinaldi <arty.net2 at gmail.com <javascript:;>> wrote:
> > I finally see ! So these were my last steps :
> >
> > $ sudo sh setuptools-0.6c11-py2.7.egg
> > $ sudo easy_install -m setuptools
> >
> > sudo rm /Library/Python/2.7/site-packages/setuptools.pth
> > sudo rm /Library/Python/2.7/site-packages/setuptools-0.6c11-py2.7.egg
> > sudo rm /usr/local/bin/easy_install
> > sudo rm /usr/local/bin/easy_install-2.7
> >
> > in a few words, I removed all the stuff installed in the first step
> > (and that apperead in the stdout)....is it all right now ? In the
> > future i will only use the python-packages built with macports (i.e.
> > py27-numpy). I asked help because I was very confused with all that
> > stuff....thx very much for replying me so soon.
>
> Well, removing those files won't hurt but, if you set your PATH as
> suggested, it shouldn't make any difference either.  The MacPorts files
> are installed in a completely separate location and one of the
> advantages of OS X Python framework installs is that multiple versions
> can co-exist on the same system without interfering with each other.
>
> --
>  Ned Deily,
>  nad at acm.org <javascript:;>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org <javascript:;>
> http://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120516/a17c542a/attachment.html>

From tarek at ziade.org  Wed May 16 08:35:42 2012
From: tarek at ziade.org (=?UTF-8?B?VGFyZWsgWmlhZMOp?=)
Date: Wed, 16 May 2012 08:35:42 +0200
Subject: [Distutils] command hooks...
In-Reply-To: <4FB309B3.5060406@plope.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
Message-ID: <4FB34ABE.5050108@ziade.org>

On 5/16/12 3:58 AM, Chris McDonough wrote:
> On 05/15/2012 04:39 PM, ?ric Araujo wrote:
>> Hi again,
>>
>> Le 01/05/2012 14:28, Paul Moore a ?crit :
>>> On 1 May 2012 17:40, Chris McDonough<chrism at plope.com> wrote:
>>>> Is there a PEP for the "packaging" package? Is there any sort of
>>>> unfinished
>>>> business I can help with?
>>> AFAIK, there's no specific PEP for packaging (there are a number of
>>> related PEPs, but nothing specific like a roadmap).
>> Yep. distutils2/packaging implement PEP 345 (Metadata 1.2), 376
>> (dist-info directory a.k.a. installation database) and 386 (version
>> numbers), and also the older Metadata PEPs like distutils, but there was
>> no PEP to discuss inclusion of d2 in Python 3.3: it just happened when a
>> core developer (Martin von L?wis) indicated he was opposed to work on
>> features (to add support for PEP 384 ? Stable ABI for example) outside
>> of the Python repository. I think that no PEP was asked by anyone
>> because distutils2 is forked from code already in the stdlib and it
>> implements accepted PEPs. There are small and big features added or in
>> progress, many of them inspired by setuptools, that don?t have a PEP
>> though.
>>
>> As I said on my other reply there is no friendly list of issues or
>> roadmap, only unsorted bugs and what?s in my mind.
>
> OK.  Is there a way for me to take a look at the unsorted bugs?
>
>>> I'm sure ?ric can give you much better pointers on what would be
>>> useful, but one issue I've tried to raise a few times, and more
>>> recently Jim Fulton raised here
>>> (http://mail.python.org/pipermail/distutils-sig/2012-March/018323.html)
>>> is that of binary distribution support in packaging2. I've never had
>>> the time to shepherd a proposal through beyond the "initial debate"
>>> stage, and I know it's not getting high on ?ric's list of priorities,
>>> but it would be good to see some movement on this.
>> Indeed, in private email with Paul I agreed on the importance of a
>> binary distribution format and did a pre-publication review of his PEP,
>> but we did not finish our discussion nor incorporated the alternate
>> proposal that was discussed at PyCon and on the mailing list (which
>> makes it hard to see a clear picture ? PEPs are good :)
>>
>> It seems unlikely that this hard topic can be solved for Python 3.3 /
>> distutils2 1.0; what can be done however is to make sure that the
>> extensibility hooks in d2 are well tested and documented so that when a
>> bdist PEP reaches agreement and is implemented, a simple pysetup call
>> and two lines of config will be all it takes to be able to use the new
>> command.
>>
>> I know that the situation is far from ideal, and far from our goals for
>> 3.3, but anyway d2 was never intended as a full replacement for
>> setuptools and pip (more on that in an upcoming reply to another of your
>> messages when you listed the setuptools features used by Pyramid). I
>> think packaging in Python 3.3 will be a first version put in the stdlib
>> to gather feedback and reports, not a finished stable product.
>
> I really don't want to add stop energy here, and I'm more than willing 
> to row to get something going, but I'm afraid if that's the diagnosis, 
> it means I'll personally have to oppose the inclusion of packaging in 
> 3.3.  We currently already have at least 3 competing solutions 
> (setuptools, distribute, and distutils itself), and people are baffled 
> about which to use and how to use it.  Adding two more (packaging and 
> distutils2) which are similarly semi-documented and which don't even 
> solve the problems that the previous ones do would serve no purpose, 
> and baking them into Python itself will mean they can't evolve in 
> important ways.   I'd suggest we just put the brakes on and slate 
> something better for 3.4.  Does that make sense, or does that make 
> people sad?
I know the idea of having packaging in the stdlib is something some 
people disliked, from day 1. And if I recall correctly, you did not like 
this either back then.

I am -1 on for two reasons:

1/ your argument about people being baffled about which tool to use will 
be worse if we work outside the stdlib. Having packaging in the stdlib 
and distutils frozen here, leads the path: "hey, the next tool in the 
stdlib is packaging"

2/ packaging is completely mature for some parts, like the PEP 386 
implementation. And having the packaging.version module in the stdlib is 
a great step forward for standardization
     The pep 376 implementation is also providing great APIs to push all 
tools to inter-operate.

If we develop this tool outside, I am afraid we will just add more 
confusion in the mix.

Can you see packaging as a set of utility at this point, rather than a 
tool that's going to replace instantly all the legacy tools ?

I am adding Guido in cc for his opinion on this

Cheers
Tarek


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


From tarek at ziade.org  Wed May 16 08:42:35 2012
From: tarek at ziade.org (=?UTF-8?B?VGFyZWsgWmlhZMOp?=)
Date: Wed, 16 May 2012 08:42:35 +0200
Subject: [Distutils] command hooks...
In-Reply-To: <jov5am$kh4$1@dough.gmane.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<jov5am$kh4$1@dough.gmane.org>
Message-ID: <4FB34C5B.5040409@ziade.org>

On 5/16/12 5:01 AM, Alex Clark wrote:
> Hi,
>
> On 5/15/12 9:58 PM, Chris McDonough wrote:
>> On 05/15/2012 04:39 PM, ?ric Araujo wrote:
>>> Hi again,
>>>
>>> Le 01/05/2012 14:28, Paul Moore a ?crit :
>>>> On 1 May 2012 17:40, Chris McDonough<chrism at plope.com> wrote:
>>>>> Is there a PEP for the "packaging" package? Is there any sort of
>>>>> unfinished
>>>>> business I can help with?
>>>> AFAIK, there's no specific PEP for packaging (there are a number of
>>>> related PEPs, but nothing specific like a roadmap).
>>> Yep. distutils2/packaging implement PEP 345 (Metadata 1.2), 376
>>> (dist-info directory a.k.a. installation database) and 386 (version
>>> numbers), and also the older Metadata PEPs like distutils, but there 
>>> was
>>> no PEP to discuss inclusion of d2 in Python 3.3: it just happened 
>>> when a
>>> core developer (Martin von L?wis) indicated he was opposed to work on
>>> features (to add support for PEP 384 ? Stable ABI for example) outside
>>> of the Python repository. I think that no PEP was asked by anyone
>>> because distutils2 is forked from code already in the stdlib and it
>>> implements accepted PEPs. There are small and big features added or in
>>> progress, many of them inspired by setuptools, that don?t have a PEP
>>> though.
>>>
>>> As I said on my other reply there is no friendly list of issues or
>>> roadmap, only unsorted bugs and what?s in my mind.
>>
>> OK. Is there a way for me to take a look at the unsorted bugs?
>>
>>>> I'm sure ?ric can give you much better pointers on what would be
>>>> useful, but one issue I've tried to raise a few times, and more
>>>> recently Jim Fulton raised here
>>>> (http://mail.python.org/pipermail/distutils-sig/2012-March/018323.html) 
>>>>
>>>> is that of binary distribution support in packaging2. I've never had
>>>> the time to shepherd a proposal through beyond the "initial debate"
>>>> stage, and I know it's not getting high on ?ric's list of priorities,
>>>> but it would be good to see some movement on this.
>>> Indeed, in private email with Paul I agreed on the importance of a
>>> binary distribution format and did a pre-publication review of his PEP,
>>> but we did not finish our discussion nor incorporated the alternate
>>> proposal that was discussed at PyCon and on the mailing list (which
>>> makes it hard to see a clear picture ? PEPs are good :)
>>>
>>> It seems unlikely that this hard topic can be solved for Python 3.3 /
>>> distutils2 1.0; what can be done however is to make sure that the
>>> extensibility hooks in d2 are well tested and documented so that when a
>>> bdist PEP reaches agreement and is implemented, a simple pysetup call
>>> and two lines of config will be all it takes to be able to use the new
>>> command.
>>>
>>> I know that the situation is far from ideal, and far from our goals for
>>> 3.3, but anyway d2 was never intended as a full replacement for
>>> setuptools and pip (more on that in an upcoming reply to another of 
>>> your
>>> messages when you listed the setuptools features used by Pyramid). I
>>> think packaging in Python 3.3 will be a first version put in the stdlib
>>> to gather feedback and reports, not a finished stable product.
>>
>> I really don't want to add stop energy here, and I'm more than willing
>> to row to get something going, but I'm afraid if that's the diagnosis,
>> it means I'll personally have to oppose the inclusion of packaging in
>> 3.3. We currently already have at least 3 competing solutions
>> (setuptools, distribute, and distutils itself), and people are baffled
>> about which to use and how to use it. Adding two more (packaging and
>> distutils2) which are similarly semi-documented and which don't even
>> solve the problems that the previous ones do would serve no purpose, and
>> baking them into Python itself will mean they can't evolve in important
>> ways. I'd suggest we just put the brakes on and slate something better
>> for 3.4. Does that make sense, or does that make people sad?
>
>
> +1. I think that makes sense. I'd be willing to work on something if I 
> felt like I understood what was going on, which I don't. For example, 
> distribute's goal seems very clear: provide a well-maintained and 
> frequently-released setuptools. It would make sense (to me) to include 
> distribute in a future release of Python, to close the loop of the 
> non-std-lib-packaging-lib-built-on-top-distutils-but-never-included-in-the-stdlib-situation. 

This will never happen because Distribute's goal was 1/ to allow us to 
fix some bugs in setuptools and 2/ set some bridges for "packaging" 
adoption. But the final goal is to let it die where it is.



> But IIUC, it's too convoluted to attempt such a thing, and 
> distutils2/packaging was meant to provide us the freedom to break 
> backwards compat, but to what end? I don't think I fully understand 
> the over-arching, real-world practical goals are for packaging in 
> Python 3.x (other than to provide the pysetup command, and ini-style 
> configuration over setup.py.)
packaging provides two things:
- reference implementations for the PEPs we've written - that can be 
used by any tool
- a replacement for distutils-the-tool, with improvements and backward 
compatible helpers, like a way to browse packages installed by other tools

The only reason we did  not do this in distutils was because any change 
I made in the code back then, even on private parts, was potentially 
breaking all the legacy code out there
>
>
> Alex
>
>
>>
>> - C
>> _______________________________________________
>> Distutils-SIG maillist - Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>
>


From tarek at ziade.org  Wed May 16 08:55:08 2012
From: tarek at ziade.org (=?UTF-8?B?VGFyZWsgWmlhZMOp?=)
Date: Wed, 16 May 2012 08:55:08 +0200
Subject: [Distutils] command hooks...
In-Reply-To: <4FB309B3.5060406@plope.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
Message-ID: <4FB34F4C.9080901@ziade.org>

On 5/16/12 3:58 AM, Chris McDonough wrote:
> Adding two more (packaging and distutils2) which are similarly 
> semi-documented and which don't even solve the problems that the 
> previous ones do would serve no purpose, and baking them into Python 
> itself will mean they can't evolve in important ways.

Oh, I think I need to answer to this too since you said you wanted to 
help. Packaging is not intended to be similar to setuptools in its features.

For instance we won't provide console scripts or entry points. The first 
one because 'script' is the same feature (except there's an indirection 
and I said before we could mimic this)
The second one because we should build this kind of feature outside the 
stdlib (this is not something most people use, according to the survey I 
did back a few years ago, it's mostly zope/plone/repoze land)

I'd suggest you list what you can't do with "packaging" today and we 
work through that list to point which features are missing and should be 
developed *outside* the standard lib, and which ones are in "packaging" 
or should be

IOW: packaging should only be the common basis and provide a basic 
installer - not a full fledge tool you can use to replace the most 
advanced setuptools features. And we want it pluggable enough so people 
can build pluggable features on the top of it, like Eric explained earlier

Does that make sense ?

Cheers
Tarek


From donald.stufft at gmail.com  Wed May 16 09:25:12 2012
From: donald.stufft at gmail.com (Donald Stufft)
Date: Wed, 16 May 2012 03:25:12 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FB34F4C.9080901@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org>
Message-ID: <76DEAF48069E4F1CBB981F4AF45D0251@gmail.com>

I think the biggest thing missing wrt to command hooks is the ability  
to have the tool automatically generate a OS specific wrapper (.exe for
windows, extension less with a shebang for *NIX). While I think it would
be useful for this feature to live in std lib, I don't think it's near as required
as getting the core of packaging into stdlib.

Attempting to create packaging as outside of stdlib brings up images
of http://xkcd.com/927/, and to me the only thing prevent packaging
from just being another standard is the "Blessing" that comes with
being in stdlib.


On Wednesday, May 16, 2012 at 2:55 AM, Tarek Ziad? wrote:

> On 5/16/12 3:58 AM, Chris McDonough wrote:
> > Adding two more (packaging and distutils2) which are similarly  
> > semi-documented and which don't even solve the problems that the  
> > previous ones do would serve no purpose, and baking them into Python  
> > itself will mean they can't evolve in important ways.
> >  
>  
>  
> Oh, I think I need to answer to this too since you said you wanted to  
> help. Packaging is not intended to be similar to setuptools in its features.
>  
> For instance we won't provide console scripts or entry points. The first  
> one because 'script' is the same feature (except there's an indirection  
> and I said before we could mimic this)
> The second one because we should build this kind of feature outside the  
> stdlib (this is not something most people use, according to the survey I  
> did back a few years ago, it's mostly zope/plone/repoze land)
>  
> I'd suggest you list what you can't do with "packaging" today and we  
> work through that list to point which features are missing and should be  
> developed *outside* the standard lib, and which ones are in "packaging"  
> or should be
>  
> IOW: packaging should only be the common basis and provide a basic  
> installer - not a full fledge tool you can use to replace the most  
> advanced setuptools features. And we want it pluggable enough so people  
> can build pluggable features on the top of it, like Eric explained earlier
>  
> Does that make sense ?
>  
> Cheers
> Tarek
>  
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org (mailto:Distutils-SIG at python.org)
> http://mail.python.org/mailman/listinfo/distutils-sig
>  
>  


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

From p.f.moore at gmail.com  Wed May 16 09:40:47 2012
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 16 May 2012 08:40:47 +0100
Subject: [Distutils] command hooks...
In-Reply-To: <4FB34F4C.9080901@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org>
Message-ID: <CACac1F8CnijSFnNSPyyJmgQ71O2yfxVgVb4kU0f_bdpuf_sM2w@mail.gmail.com>

On 16 May 2012 07:55, Tarek Ziad? <tarek at ziade.org> wrote:

> I'd suggest you list what you can't do with "packaging" today and we work
> through that list to point which features are missing and should be
> developed *outside* the standard lib, and which ones are in "packaging" or
> should be

This would be a very good step - but rather than simply getting
responses in the mailing list, can I suggest that we need some sort of
central location where the features still outstanding for packaging
can be tracked. Call it a roadmap if you like. Maybe it should be a
PEP - simply because I can't think of a better place to put it, but
I'm open to suggestions (I don't think the bug tracker is the right
place, fwiw).

At the moment, the biggest issue I see is that there are lots of
discussions about what people believe is missing, but nothing clearly
documenting what's intended to be there (and what is not - for
example, your comment about entry points).

As a starter, my key "missing requirement" is support for binary
distributions - whether this is a new "universal" format, or whether
it is reusing the bdist_wininst/bdist_msi formats, I don't really
care, but it needs to be formalised with a migration path, backward
compatibility support considered, etc.

> IOW: packaging should only be the common basis and provide a basic installer
> - not a full fledge tool you can use to replace the most advanced setuptools
> features. And we want it pluggable enough so people can build pluggable
> features on the top of it, like Eric explained earlier
>
> Does that make sense ?

I would assume as a first guess that it should replace all of
distutils, though? Ideally there should be no reason for people to use
distutils for anything once packaging is available - am I right?

Paul.

From tarek at ziade.org  Wed May 16 09:49:08 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 16 May 2012 09:49:08 +0200
Subject: [Distutils] command hooks...
In-Reply-To: <CACac1F8CnijSFnNSPyyJmgQ71O2yfxVgVb4kU0f_bdpuf_sM2w@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org>
	<CACac1F8CnijSFnNSPyyJmgQ71O2yfxVgVb4kU0f_bdpuf_sM2w@mail.gmail.com>
Message-ID: <4FB35BF4.80003@ziade.org>

On 5/16/12 9:40 AM, Paul Moore wrote:
> On 16 May 2012 07:55, Tarek Ziad?<tarek at ziade.org>  wrote:
>
>> I'd suggest you list what you can't do with "packaging" today and we work
>> through that list to point which features are missing and should be
>> developed *outside* the standard lib, and which ones are in "packaging" or
>> should be
> This would be a very good step - but rather than simply getting
> responses in the mailing list, can I suggest that we need some sort of
> central location where the features still outstanding for packaging
> can be tracked. Call it a roadmap if you like. Maybe it should be a
> PEP - simply because I can't think of a better place to put it, but
> I'm open to suggestions (I don't think the bug tracker is the right
> place, fwiw).
A wiki page sounds good, as long as each point turns into a bug at some 
point


> At the moment, the biggest issue I see is that there are lots of
> discussions about what people believe is missing, but nothing clearly
> documenting what's intended to be there (and what is not - for
> example, your comment about entry points).
>
> As a starter, my key "missing requirement" is support for binary
> distributions - whether this is a new "universal" format, or whether
> it is reusing the bdist_wininst/bdist_msi formats, I don't really
> care, but it needs to be formalised with a migration path, backward
> compatibility support considered, etc.

Do you feel like you could start the windows story section on that wiki 
page ?

>
>> IOW: packaging should only be the common basis and provide a basic installer
>> - not a full fledge tool you can use to replace the most advanced setuptools
>> features. And we want it pluggable enough so people can build pluggable
>> features on the top of it, like Eric explained earlier
>>
>> Does that make sense ?
> I would assume as a first guess that it should replace all of
> distutils, though? Ideally there should be no reason for people to use
> distutils for anything once packaging is available - am I right?
It does replace all distutils since it's a fork of it.

The parts that is missing on purpose is bdist_rpm because we want 
anything RPM-related to
be dealt outside the stdlib : there's a whole gap between how 
rhel/fedora guys do their packaging
and what we offer with bdist_rpm, which seems to be perfect for... red 
hat 4 ?

FWIW I have started the pypi2rpm project to group tools for RPM-izing 
python projects.

Windows binaries were kept because it seems easy and feasible to 
maintain those from the stdlib --
but they still smell like old stuff because we don't have a Mr Windows 
in the distutils project.

It was mostly Martin doing the legit work to make it work, and a couple 
of other people (forgive
me if I forget someone)

So... the windows binary story will improve if we get a champion for this.

Cheers
Tarek


From p.f.moore at gmail.com  Wed May 16 10:30:56 2012
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 16 May 2012 09:30:56 +0100
Subject: [Distutils] command hooks...
In-Reply-To: <4FB35BF4.80003@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org>
	<CACac1F8CnijSFnNSPyyJmgQ71O2yfxVgVb4kU0f_bdpuf_sM2w@mail.gmail.com>
	<4FB35BF4.80003@ziade.org>
Message-ID: <CACac1F_1nrgbqupO0uJEGbQX8xk0rdJbFOM_rNqkSGmZULT3-Q@mail.gmail.com>

On 16 May 2012 08:49, Tarek Ziad? <tarek at ziade.org> wrote:
> On 5/16/12 9:40 AM, Paul Moore wrote:
>> This would be a very good step - but rather than simply getting
>> responses in the mailing list, can I suggest that we need some sort of
>> central location where the features still outstanding for packaging
>> can be tracked. Call it a roadmap if you like. Maybe it should be a
>> PEP - simply because I can't think of a better place to put it, but
>> I'm open to suggestions (I don't think the bug tracker is the right
>> place, fwiw).
>
> A wiki page sounds good, as long as each point turns into a bug at some
> point

That sounds reasonable, I guess. As long as it's easy for people to find.

>> As a starter, my key "missing requirement" is support for binary
>> distributions - whether this is a new "universal" format, or whether
>> it is reusing the bdist_wininst/bdist_msi formats, I don't really
>> care, but it needs to be formalised with a migration path, backward
>> compatibility support considered, etc.
>
> Do you feel like you could start the windows story section on that wiki page
> ?

I'm happy to summarise this on there. Let me know a link to the wiki
page. But 2 points:

1. Binary distributions is *not* a Windows issue. I originally pitched
it as such, because that's where I care, but other people chimed in
with an interest from a non-Windows POV. I can't comment on those
requirements, though. And part of the problem is getting someone to
make a unified statement. I drafted a PEP based around this, but ?ric
wanted to have a think about it, and it stalled. We also had other
suggestions from Jim Fulton and Vinay Sanjip on various lists. So
someone needs to take a lead on unifying all this.

2. The main Windows issue is that there are still a lot of bugs.
Whenever I test stuff, I usually find myself hitting one or two bugs,
often existing ones (I don't often get to report new bugs :-)) and
then I'm stuck, unless I fix those bugs, which I often can't (or don't
have the time to). So my efforts stall. I'll have another try at using
packaging in the 3.3a2 release and see what the picture looks like
now. (Note - my key use case at the moment is pysetup install stuff
from pypi, I'm not writing my own packages, so it's the backward
compatibility with existing distutils-based packages that I'll be
testing, and which is key for me).

> Windows binaries were kept because it seems easy and feasible to maintain
> those from the stdlib --
> but they still smell like old stuff because we don't have a Mr Windows in
> the distutils project.
>
> It was mostly Martin doing the legit work to make it work, and a couple of
> other people (forgive
> me if I forget someone)
>
> So... the windows binary story will improve if we get a champion for this.

Agreed. Unfortunately, I don't have the time to be such a champion.
But nevertheless, the current story with
distutils/setuptools/distribute on Windows is perfectly fine, so
unless packaging can get to that standard, I can't honestly suggest to
people that they should switch over. It's a high bar to reach
(particularly with such limited Windows expertise available) but
necessary, IMO.

Paul.

From tarek at ziade.org  Wed May 16 10:42:04 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 16 May 2012 10:42:04 +0200
Subject: [Distutils] command hooks...
In-Reply-To: <CACac1F_1nrgbqupO0uJEGbQX8xk0rdJbFOM_rNqkSGmZULT3-Q@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org>
	<CACac1F8CnijSFnNSPyyJmgQ71O2yfxVgVb4kU0f_bdpuf_sM2w@mail.gmail.com>
	<4FB35BF4.80003@ziade.org>
	<CACac1F_1nrgbqupO0uJEGbQX8xk0rdJbFOM_rNqkSGmZULT3-Q@mail.gmail.com>
Message-ID: <4FB3685C.4060809@ziade.org>

Taking off Guido, I don't think he needs to be in the whole thread

On 5/16/12 10:30 AM, Paul Moore wrote:
> I'm happy to summarise this on there. Let me know a link to the wiki 
> page. 
I created http://wiki.python.org/moin/Packaging/Roadmap


> But 2 points:
>
> 1. Binary distributions is *not* a Windows issue. I originally pitched
> it as such, because that's where I care, but other people chimed in
> with an interest from a non-Windows POV. I can't comment on those
> requirements, though. And part of the problem is getting someone to
> make a unified statement. I drafted a PEP based around this, but ?ric
> wanted to have a think about it, and it stalled. We also had other
> suggestions from Jim Fulton and Vinay Sanjip on various lists. So
> someone needs to take a lead on unifying all this.
Yeah definitely agreed. Although it impacts windows the most because 
it's easier on other platform
to deal with source archives.

>
> 2. The main Windows issue is that there are still a lot of bugs.
> Whenever I test stuff, I usually find myself hitting one or two bugs,
> often existing ones (I don't often get to report new bugs :-)) and
> then I'm stuck, unless I fix those bugs, which I often can't (or don't
> have the time to). So my efforts stall.

Yeah. And those bugs where in Distutils. What I mean is that Packaging 
has not improved much in this corner of distutils,
but has not made it worse, and the tools are still accessible under the 
new version.

>   I'll have another try at using
> packaging in the 3.3a2 release and see what the picture looks like
> now. (Note - my key use case at the moment is pysetup install stuff
> from pypi, I'm not writing my own packages, so it's the backward
> compatibility with existing distutils-based packages that I'll be
> testing, and which is key for me).
Ok thanks
>
>> Windows binaries were kept because it seems easy and feasible to maintain
>> those from the stdlib --
>> but they still smell like old stuff because we don't have a Mr Windows in
>> the distutils project.
>>
>> It was mostly Martin doing the legit work to make it work, and a couple of
>> other people (forgive
>> me if I forget someone)
>>
>> So... the windows binary story will improve if we get a champion for this.
> Agreed. Unfortunately, I don't have the time to be such a champion.
> But nevertheless, the current story with
> distutils/setuptools/distribute on Windows is perfectly fine, so
> unless packaging can get to that standard, I can't honestly suggest to
> people that they should switch over. It's a high bar to reach
> (particularly with such limited Windows expertise available) but
> necessary, IMO.
Definitely ! I am afraid the scope is so wide that it's impossible to 
address all problems for v1

Another part were we lack a champion: compilers


>
> Paul.


From jim at zope.com  Wed May 16 15:19:23 2012
From: jim at zope.com (Jim Fulton)
Date: Wed, 16 May 2012 09:19:23 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FB34F4C.9080901@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org>
Message-ID: <CAPDm-FhvUX51+KV-TOfc4qBzFkAuJzpbxNhKqppsuwOtuA20PA@mail.gmail.com>

On Wed, May 16, 2012 at 2:55 AM, Tarek Ziad? <tarek at ziade.org> wrote:
> On 5/16/12 3:58 AM, Chris McDonough wrote:
>>
>> Adding two more (packaging and distutils2) which are similarly
>> semi-documented and which don't even solve the problems that the previous
>> ones do would serve no purpose, and baking them into Python itself will mean
>> they can't evolve in important ways.
>
>
> Oh, I think I need to answer to this too since you said you wanted to help.
> Packaging is not intended to be similar to setuptools in its features.
>
> For instance we won't provide console scripts or entry points. The first one
> because 'script' is the same feature (except there's an indirection and I
> said before we could mimic this)

I don't know what this means.  Will we have something
functionally-equivalent to console-scripts?  Or will we have something
more similar to the old distutils scripts functionality.  If the
later, then I doubt that packaging will work well with buildout.

Jim

From tarek at ziade.org  Wed May 16 15:26:23 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 16 May 2012 15:26:23 +0200
Subject: [Distutils] command hooks...
In-Reply-To: <CAPDm-FhvUX51+KV-TOfc4qBzFkAuJzpbxNhKqppsuwOtuA20PA@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org>
	<CAPDm-FhvUX51+KV-TOfc4qBzFkAuJzpbxNhKqppsuwOtuA20PA@mail.gmail.com>
Message-ID: <4FB3AAFF.9000006@ziade.org>

On 5/16/12 3:19 PM, Jim Fulton wrote:
> On Wed, May 16, 2012 at 2:55 AM, Tarek Ziad?<tarek at ziade.org>  wrote:
>> On 5/16/12 3:58 AM, Chris McDonough wrote:
>>> Adding two more (packaging and distutils2) which are similarly
>>> semi-documented and which don't even solve the problems that the previous
>>> ones do would serve no purpose, and baking them into Python itself will mean
>>> they can't evolve in important ways.
>>
>> Oh, I think I need to answer to this too since you said you wanted to help.
>> Packaging is not intended to be similar to setuptools in its features.
>>
>> For instance we won't provide console scripts or entry points. The first one
>> because 'script' is the same feature (except there's an indirection and I
>> said before we could mimic this)
> I don't know what this means.  Will we have something
> functionally-equivalent to console-scripts?  Or will we have something
> more similar to the old distutils scripts functionality.  If the
> later, then I doubt that packaging will work well with buildout.

Please explain us exactly what you mean with this feature.

What we want to have in packaging is the old distutils srcipt feature, 
with an extra option:
a way to point a callable instead of a module, and then a wrapper like 
setuptools does.

If you need something else, please explain what it is.

(there's no need to declare an entry point and iterate over all 
projects, just to find back a
  callable to run your script, right? you can just... import the callable)


>
> Jim


From jim at zope.com  Wed May 16 17:25:48 2012
From: jim at zope.com (Jim Fulton)
Date: Wed, 16 May 2012 11:25:48 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FB3AAFF.9000006@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org>
	<CAPDm-FhvUX51+KV-TOfc4qBzFkAuJzpbxNhKqppsuwOtuA20PA@mail.gmail.com>
	<4FB3AAFF.9000006@ziade.org>
Message-ID: <CAPDm-Fht9h=77=fMjYaS9oPP6Rns6WDrpgR7szNPx6bN_2uHCA@mail.gmail.com>

On Wed, May 16, 2012 at 9:26 AM, Tarek Ziad? <tarek at ziade.org> wrote:
> On 5/16/12 3:19 PM, Jim Fulton wrote:
>>
>> On Wed, May 16, 2012 at 2:55 AM, Tarek Ziad?<tarek at ziade.org> ?wrote:
>>>
>>> On 5/16/12 3:58 AM, Chris McDonough wrote:
>>>>
>>>> Adding two more (packaging and distutils2) which are similarly
>>>> semi-documented and which don't even solve the problems that the
>>>> previous
>>>> ones do would serve no purpose, and baking them into Python itself will
>>>> mean
>>>> they can't evolve in important ways.
>>>
>>>
>>> Oh, I think I need to answer to this too since you said you wanted to
>>> help.
>>> Packaging is not intended to be similar to setuptools in its features.
>>>
>>> For instance we won't provide console scripts or entry points. The first
>>> one
>>> because 'script' is the same feature (except there's an indirection and I
>>> said before we could mimic this)
>>
>> I don't know what this means. ?Will we have something
>> functionally-equivalent to console-scripts? ?Or will we have something
>> more similar to the old distutils scripts functionality. ?If the
>> later, then I doubt that packaging will work well with buildout.
>
>
> Please explain us exactly what you mean with this feature.
>
> What we want to have in packaging is the old distutils srcipt feature, with
> an extra option:
> a way to point a callable instead of a module, and then a wrapper like
> setuptools does.

That's exactly what buildout needs.

Jim

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

From chrism at plope.com  Wed May 16 17:49:49 2012
From: chrism at plope.com (Chris McDonough)
Date: Wed, 16 May 2012 11:49:49 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FB34ABE.5050108@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34ABE.5050108@ziade.org>
Message-ID: <4FB3CC9D.9010307@plope.com>

On 05/16/2012 02:35 AM, Tarek Ziad? wrote:
> I know the idea of having packaging in the stdlib is something some
> people disliked, from day 1. And if I recall correctly, you did not like
> this either back then.

I've always been pro-stdlib-contains-a-package-installer-and-machinery, 
and I still am.

> I am -1 on for two reasons:
>
> 1/ your argument about people being baffled about which tool to use will
> be worse if we work outside the stdlib. Having packaging in the stdlib
> and distutils frozen here, leads the path: "hey, the next tool in the
> stdlib is packaging"

It's fine to develop it inside the stdlib.  It's harder to think about 
releasing it in 3.3 though without good docs.  Do you think we have 
enough time to document it and define its scope and limitations and 
future plans in written form before 3.3beta1 ships?

> 2/ packaging is completely mature for some parts, like the PEP 386
> implementation. And having the packaging.version module in the stdlib is
> a great step forward for standardization
> The pep 376 implementation is also providing great APIs to push all
> tools to inter-operate.

That's good to know.

> If we develop this tool outside, I am afraid we will just add more
> confusion in the mix.
>
> Can you see packaging as a set of utility at this point, rather than a
> tool that's going to replace instantly all the legacy tools ?

I can.

- C

From chrism at plope.com  Wed May 16 18:26:01 2012
From: chrism at plope.com (Chris McDonough)
Date: Wed, 16 May 2012 12:26:01 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FB34F4C.9080901@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org>
Message-ID: <4FB3D519.1000009@plope.com>

On 05/16/2012 02:55 AM, Tarek Ziad? wrote:
> On 5/16/12 3:58 AM, Chris McDonough wrote:
>> Adding two more (packaging and distutils2) which are similarly
>> semi-documented and which don't even solve the problems that the
>> previous ones do would serve no purpose, and baking them into Python
>> itself will mean they can't evolve in important ways.
>
> Oh, I think I need to answer to this too since you said you wanted to
> help. Packaging is not intended to be similar to setuptools in its
> features.
>
> For instance we won't provide console scripts or entry points. The first
> one because 'script' is the same feature (except there's an indirection
> and I said before we could mimic this)
> The second one because we should build this kind of feature outside the
> stdlib (this is not something most people use, according to the survey I
> did back a few years ago, it's mostly zope/plone/repoze land)

I suspect many people don't really know they're using entry points when 
they are. PasteDeploy configuration files rely heavily on entry points. 
  Those are used in various ways by Pylons, Pyramid, Zope, and 
Turbogears.  (PasteDeploy itself been downloaded almost a million times 
from PyPI.)

I'm fine with needing to depend on an external package to scan for 
entrypoint-like-things registered as the result of the installation of a 
distribution.  But there will need to be a way to register 
entrypoint-like things (along the lines of arbitrary egg-info metadata) 
as the result of distribution installation using pysetup.  Maybe that 
already exists.

> I'd suggest you list what you can't do with "packaging" today and we
> work through that list to point which features are missing and should be
> developed *outside* the standard lib, and which ones are in "packaging"
> or should be

I can try.

> IOW: packaging should only be the common basis and provide a basic
> installer - not a full fledge tool you can use to replace the most
> advanced setuptools features. And we want it pluggable enough so people
> can build pluggable features on the top of it, like Eric explained earlier
>
> Does that make sense ?

I'd like to say it does, but I'm afraid it does not.

I can see shipping both machinery and a full-fledged installer that 
handles all the use cases of existing installers.  I can also see 
shipping just machinery and no installer at all.

But I can't really see shipping both machinery and an installer that we 
know doesn't service use cases that existing installers already do.  At 
least I can't see doing that in order to service an external shipping 
deadline.

- C

From sienkiew at stsci.edu  Wed May 16 19:35:02 2012
From: sienkiew at stsci.edu (Mark Sienkiewicz)
Date: Wed, 16 May 2012 13:35:02 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FB34ABE.5050108@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34ABE.5050108@ziade.org>
Message-ID: <4FB3E546.5090500@stsci.edu>

On 05/16/2012 02:35 AM, Tarek Ziad? wrote:
>
> 1/ your argument about people being baffled about which tool to use will be worse if we work outside the stdlib. Having packaging in the stdlib and distutils frozen here, leads the path: "hey, the next tool in the stdlib is packaging"

It all depends on the documentation.

If you have complete documentation that explains how to do everything I need to do, then I can use the new tool -- someday, when I have time to read that documentation, figure out how to use it, and convert my software.

If you do not have complete documentation or if your documentation does not describe some feature that I need, then the message to me is quite clear: "Don't use this -- it doesn't do what you need".

If you want people to adopt this new tool someday, then you should avoid training everybody to think that it is incomplete and that it doesn't work.  Don't ask everybody to look at it before it is ready.

( If this were a commercial effort, you might want to release incomplete software so that you can build market share against your competitors.  But in this case, there are no alternative suppliers who might release something any day now.  There are only the legacy tools. )


> Can you see packaging as a set of utility at this point, rather than a tool that's going to replace instantly all the legacy tools ?

If it is not going to replace the legacy tools, then why should I use it?

My understanding is that the legacy tools already work, for some vague definition of "work".  Your task is to convince me that "packaging" is better -- which I think will be hard to do if packaging is not better.

Mark S.


From dholth at gmail.com  Thu May 17 06:03:20 2012
From: dholth at gmail.com (Daniel Holth)
Date: Thu, 17 May 2012 00:03:20 -0400
Subject: [Distutils] {dist-info} category in resources = ...
Message-ID: <CAG8k2+5SjZRYAL0R07Z2wnZzDtJ=L4CbaEZg=6f9PBdd11+B6w@mail.gmail.com>

My take on installing entry_points.txt is to add a {dist-info}
category in [files] resources = to copy extra files into the
.dist-info dir...

How do I write entry_points.txt when it is given as an argument to
setup(entry_points=...)? Should I write a build command hook to write
the file and a setup_hook to append the new file to [files] resources
= so it will finally be copied?

From chris.jerdonek at gmail.com  Fri May 18 15:09:22 2012
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Fri, 18 May 2012 06:09:22 -0700
Subject: [Distutils] two setup scripts
In-Reply-To: <CAOTb1we979SVxhTwFK_dc+=hp2Ltk7aHvLjHtWiM65LFTWzFPQ@mail.gmail.com>
References: <CAOTb1we979SVxhTwFK_dc+=hp2Ltk7aHvLjHtWiM65LFTWzFPQ@mail.gmail.com>
Message-ID: <CAOTb1wcvsQu25rZz6LsEQpP9Zsp8enuzLXDYOreJvDfN2n_qzQ@mail.gmail.com>

I asked the question below about a week ago.  Does anyone have any
thoughts on it?

I'll rephrase it to be simpler.  Does anyone know which arguments to
setup() it is safe to leave out when invoking run "setup.py install"
from a source distribution?  I'm assuming the source distribution
directory is one created using "setup.py sdist" (i.e. one that
contains a PKG-INFO file, a *.egg-info directory, etc).  For example,
it doesn't seem like long_description would be needed.

Since the setup() function was created to be a universal function
usable by both module developers and installers, it seems like it
would be useful to know which subset of arguments need to be provided
in the latter, simpler case.  It would also help to know where the
install command looks for and gets its information from (from the
arguments to setup(), or from the PKG-INFO file, etc).

It seems like a possible improvement to distutils would be for it to
be able to say which arguments to setup() are needed or used by which
setup commands, so that things can be more explicit.  Does that seem
like a worthwhile improvement?  It might be an intermediate step to
making the function less God-like (if that itself is a worthy goal).

Thanks,
--Chris


On Fri, May 11, 2012 at 11:36 AM, Chris Jerdonek
<chris.jerdonek at gmail.com> wrote:
> I have an open-ended question about the idea of creating two setup
> scripts for a project: one for end-users (e.g. installing), and
> another for all other use cases (e.g. project development).
>
> Here are a few reasons I came across for considering something like this:
>
> The first is that if the project needs to support, say, Python 2.4
> through Python 3.2, then having two setup scripts would let you
> require (and develop against) Python 2.7 for the developer version,
> while supporting all versions only for the simpler end-user version.
> This would also let you do things like import from the project itself
> in the developer version of your setup script, a process that would
> break if running the setup script using Python 3 (assuming you are
> using 2to3 for Python 3 support).
>
> The second is that I have a pre-processing step that requires using
> pandoc to generate setup()'s long_description from README and HISTORY
> files in markdown format prior to uploading to PyPI, and I don't want
> end-users to need pandoc. ?I am currently dealing with this in code,
> but it would be nicer to have simpler code with fewer "if blocks."
>
> The third is simply separation of concerns.
>
> This approach raises the following questions:
>
> (1) Which setup commands should each version of the script support?
>
> (2) Which arguments to setup() are required and/or used for each command?
>
> I would also like to know (2) independent of creating two setup
> scripts. ?For example, I mentioned long_description above. ?The
> long_description seems to be available in places like PKG-INFO and in
> the DOAP xml file exposed on PyPI, so is it necessary to pass
> long_description, etc to setup() for any setup command other than
> sdist (which creates PKG-INFO), or is it also necessary to pass that
> metadata to setup() even with the upload and install commands?
>
> Thanks,
> --Chris

From vinay_sajip at yahoo.co.uk  Fri May 18 17:24:59 2012
From: vinay_sajip at yahoo.co.uk (Vinay Sajip)
Date: Fri, 18 May 2012 15:24:59 +0000 (UTC)
Subject: [Distutils] Odd problem with distribute 0.6.26 and 2to3
Message-ID: <loom.20120518T165725-928@post.gmane.org>

I'm having an odd problem with distribute and 2to3 when working with the venv 
branch of Python 3.3 (PEP 405 - http://bugs.python.org/issue14712), and I'm 
hoping one of the Fellowship of the Packaging can help.

The problem: I created a venv with no Distribute installed. Then I downloaded 
and extracted distribute-0.6.26.tar.gz in a scratch folder, and ran setup.py 
install using the venv's python. This gave errors because some of the setuptools 
sources still have 2.x syntax, despite having been processed by 2to3.

To investigate further, I added logging to distutils refactoring code to print 
what was being refactored. I won't list the entire log output [1], but when 
looking at just one file which caused a SyntaxError - 
setuptools/tests/test_packageindex.py - I see the following output from the 
"setup.py install" operation:

creating build
creating build/src
...
copying setuptools/tests/test_packageindex.py -> build/src/setuptools/tests
...
copying launcher.c -> build/src
Skipping implicit fixer: buffer
Skipping implicit fixer: idioms
Skipping implicit fixer: set_literal
Skipping implicit fixer: ws_comma
refactored build/src/setuptools/script template (dev).py
...
refactored build/src/setuptools/tests/test_packageindex.py
...
refactored build/src/release.py
Before install bootstrap.
Scanning installed packages
No setuptools distribution found
running install
running build
running build_py
creating build/lib
...
copying setuptools/tests/test_packageindex.py -> build/lib/setuptools/tests
...
creating /tmp/venv/lib/python3.3/site-packages/setuptools/tests
copying build/lib/setuptools/tests/test_packageindex.py -> 
/tmp/venv/lib/python3.3/site-packages/setuptools/tests
...
running install_lib
...
creating /tmp/venv/lib/python3.3/site-packages/setuptools
creating /tmp/venv/lib/python3.3/site-packages/setuptools/tests
copying build/lib/setuptools/tests/test_packageindex.py -> 
/tmp/venv/lib/python3.3/site-packages/setuptools/tests
...
byte-compiling /tmp/venv/lib/python3.3/site-
packages/setuptools/tests/test_packageindex.py to test_packageindex.cpython-
33.pyc
...
running install_egg_info
Writing /tmp/venv/lib/python3.3/site-packages/distribute-0.6.26-py3.3.egg-info
setup.py:139: ResourceWarning: unclosed file <_io.TextIOWrapper 
name='README.txt' mode='r' encoding='UTF-8'>
  long_description = open('README.txt').read() + open('CHANGES.txt').read(),
setup.py:139: ResourceWarning: unclosed file <_io.TextIOWrapper 
name='CHANGES.txt' mode='r' encoding='UTF-8'>
  long_description = open('README.txt').read() + open('CHANGES.txt').read(),
/home/vinay/projects/python/sandbox/Lib/distutils/dist.py:257: UserWarning: 
Unknown distribution option: 'test_suite'
  warnings.warn(msg)
/home/vinay/projects/python/sandbox/Lib/distutils/dist.py:257: UserWarning: 
Unknown distribution option: 'entry_points'
  warnings.warn(msg)
/home/vinay/projects/python/sandbox/Lib/distutils/dist.py:257: UserWarning: 
Unknown distribution option: 'zip_safe'
  warnings.warn(msg)
  File "/tmp/venv/lib/python3.3/site-
packages/setuptools/tests/test_packageindex.py", line 17
    except Exception, v:
                    ^
SyntaxError: invalid syntax

Now the first part seems straightfoward: files are copied to build/src and then 
2to3 is run over them. But then, following the "No setuptools distribution 
found", files are copied to build/lib not from the 2to3-processed output at 
build/src, but rather the actual 2.x sources shipped with distribute. That looks 
wrong; at the point where setup is called, src_root is correctly set to 
build/src, and moreover, that's the first entry on sys.path. I'm not sure why 
there's no error immediately following the "byte-compiling ..." line when 
running install_lib, but the error seems to occur a little later, when running 
install_egg_info ...  

Can anyone shed any light on what's happening here?

Regards,


Vinay Sajip

[1] https://gist.github.com/2725747


From arfrever.fta at gmail.com  Fri May 18 22:30:17 2012
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 18 May 2012 22:30:17 +0200
Subject: [Distutils] Odd problem with distribute 0.6.26 and 2to3
In-Reply-To: <loom.20120518T165725-928@post.gmane.org>
References: <loom.20120518T165725-928@post.gmane.org>
Message-ID: <201205182230.18396.Arfrever.FTA@gmail.com>

2012-05-18 17:24:59 Vinay Sajip napisa?(a):
> I'm having an odd problem with distribute and 2to3 when working with the venv 
> branch of Python 3.3 (PEP 405 - http://bugs.python.org/issue14712), and I'm 
> hoping one of the Fellowship of the Packaging can help.
> 
> The problem: I created a venv with no Distribute installed. Then I downloaded 
> and extracted distribute-0.6.26.tar.gz in a scratch folder, and ran setup.py 
> install using the venv's python. This gave errors because some of the setuptools 
> sources still have 2.x syntax, despite having been processed by 2to3.
> 
> To investigate further, I added logging to distutils refactoring code to print 
> what was being refactored. I won't list the entire log output [1], but when 
> looking at just one file which caused a SyntaxError - 
> setuptools/tests/test_packageindex.py - I see the following output from the 
> "setup.py install" operation:
> 
> creating build
> creating build/src
> ...
> copying setuptools/tests/test_packageindex.py -> build/src/setuptools/tests
> ...
> copying launcher.c -> build/src
> Skipping implicit fixer: buffer
> Skipping implicit fixer: idioms
> Skipping implicit fixer: set_literal
> Skipping implicit fixer: ws_comma
> refactored build/src/setuptools/script template (dev).py
> ...
> refactored build/src/setuptools/tests/test_packageindex.py
> ...
> refactored build/src/release.py
> Before install bootstrap.
> Scanning installed packages
> No setuptools distribution found
> running install
> running build
> running build_py
> creating build/lib
> ...
> copying setuptools/tests/test_packageindex.py -> build/lib/setuptools/tests
> ...
> creating /tmp/venv/lib/python3.3/site-packages/setuptools/tests
> copying build/lib/setuptools/tests/test_packageindex.py -> 
> /tmp/venv/lib/python3.3/site-packages/setuptools/tests
> ...
> running install_lib
> ...
> creating /tmp/venv/lib/python3.3/site-packages/setuptools
> creating /tmp/venv/lib/python3.3/site-packages/setuptools/tests
> copying build/lib/setuptools/tests/test_packageindex.py -> 
> /tmp/venv/lib/python3.3/site-packages/setuptools/tests
> ...
> byte-compiling /tmp/venv/lib/python3.3/site-
> packages/setuptools/tests/test_packageindex.py to test_packageindex.cpython-
> 33.pyc
> ...
> running install_egg_info
> Writing /tmp/venv/lib/python3.3/site-packages/distribute-0.6.26-py3.3.egg-info
> setup.py:139: ResourceWarning: unclosed file <_io.TextIOWrapper 
> name='README.txt' mode='r' encoding='UTF-8'>
>   long_description = open('README.txt').read() + open('CHANGES.txt').read(),
> setup.py:139: ResourceWarning: unclosed file <_io.TextIOWrapper 
> name='CHANGES.txt' mode='r' encoding='UTF-8'>
>   long_description = open('README.txt').read() + open('CHANGES.txt').read(),
> /home/vinay/projects/python/sandbox/Lib/distutils/dist.py:257: UserWarning: 
> Unknown distribution option: 'test_suite'
>   warnings.warn(msg)
> /home/vinay/projects/python/sandbox/Lib/distutils/dist.py:257: UserWarning: 
> Unknown distribution option: 'entry_points'
>   warnings.warn(msg)
> /home/vinay/projects/python/sandbox/Lib/distutils/dist.py:257: UserWarning: 
> Unknown distribution option: 'zip_safe'
>   warnings.warn(msg)
>   File "/tmp/venv/lib/python3.3/site-
> packages/setuptools/tests/test_packageindex.py", line 17
>     except Exception, v:
>                     ^
> SyntaxError: invalid syntax
> 
> Now the first part seems straightfoward: files are copied to build/src and then 
> 2to3 is run over them. But then, following the "No setuptools distribution 
> found", files are copied to build/lib not from the 2to3-processed output at 
> build/src, but rather the actual 2.x sources shipped with distribute. That looks 
> wrong; at the point where setup is called, src_root is correctly set to 
> build/src, and moreover, that's the first entry on sys.path. I'm not sure why 
> there's no error immediately following the "byte-compiling ..." line when 
> running install_lib, but the error seems to occur a little later, when running 
> install_egg_info ...  
> 
> Can anyone shed any light on what's happening here?

Try with Distribute 0.6.27, which fixes support for current snapshots of CPython 3.3.

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120518/973bbb96/attachment.pgp>

From robhealey1 at gmail.com  Sat May 19 05:14:29 2012
From: robhealey1 at gmail.com (Rob Healey)
Date: Fri, 18 May 2012 20:14:29 -0700
Subject: [Distutils] Distutils2 in Python-3.3.0
Message-ID: <CAAq8yduKGkPEOwEngQ3LCjjkdmJBf+uFEuhSwgAEyBcvuiSVTw@mail.gmail.com>

Good evening to all!

I am also willing to help out too...

What is the process for submitting patches?  But I must, in all respects,
patches are USELESS without someone to commit them!!!

There needs to be more than one person who can commit the patches...

-- 
Sincerely yours,
Rob G. Healey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120518/bf22cf1d/attachment-0001.html>

From dholth at gmail.com  Sat May 19 06:05:04 2012
From: dholth at gmail.com (Daniel Holth)
Date: Sat, 19 May 2012 00:05:04 -0400
Subject: [Distutils] Distutils2 in Python-3.3.0
In-Reply-To: <CAAq8yduKGkPEOwEngQ3LCjjkdmJBf+uFEuhSwgAEyBcvuiSVTw@mail.gmail.com>
References: <CAAq8yduKGkPEOwEngQ3LCjjkdmJBf+uFEuhSwgAEyBcvuiSVTw@mail.gmail.com>
Message-ID: <CAG8k2+6nusfxPxkjVUXKZAUKpiT9ePez_KiShxWAB8yEw9TeuA@mail.gmail.com>

I think the process may be to checkout Python from
hg.python.org/cpython, edit the 'packaging' module, and then those
fixes should wind up in the next distutils2 backport. I've been using
bitbucket to publish my changes, and the Python bug tracker can
generate patches from external Mercurial repositories.

I've already implemented two things that are important to me in
http://bitbucket.org/dholth/cpython . A {dist-info} category in
setup.cfg to add arbitrary files to the .dist-info directory (intended
for entry_points.txt) Python bug #11880.

And nearly-PEP-376-compliant relative paths in RECORD, because I
really want to be able to move site-packages around (or use a chroot)
without rewriting RECORD.

Does PEP-317 really mean to say "use / instead of os.path.sep for
relative paths on any platform, but the platform path separator on
absolute paths"? I notice pip uses paths relative to the .egg-info
directory instead of its parent directory which seems a bit simpler to
implement, but not every path can be relative on Windows.

Daniel

From robhealey1 at gmail.com  Sat May 19 06:49:17 2012
From: robhealey1 at gmail.com (Rob Healey)
Date: Fri, 18 May 2012 21:49:17 -0700
Subject: [Distutils] packaging in Python-3.3.0 ???
Message-ID: <CAAq8ydtjaMX+Bp2H=d8ddU2HCNN32+UQT59ywDFFETBP+yOKUg@mail.gmail.com>

Hello once agai:

Is packaging in Python-3.3.0 a more complete software than DU2???  If it
is, then I will start using it instead...?

-- 
Sincerely yours,
Rob G. Healey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120518/d9162d6d/attachment.html>

From dholth at gmail.com  Sat May 19 13:01:01 2012
From: dholth at gmail.com (Daniel Holth)
Date: Sat, 19 May 2012 07:01:01 -0400
Subject: [Distutils] packaging in Python-3.3.0 ???
In-Reply-To: <CAAq8ydtjaMX+Bp2H=d8ddU2HCNN32+UQT59ywDFFETBP+yOKUg@mail.gmail.com>
References: <CAAq8ydtjaMX+Bp2H=d8ddU2HCNN32+UQT59ywDFFETBP+yOKUg@mail.gmail.com>
Message-ID: <38F6F205-1184-4307-AB87-F294BD8FD3FD@gmail.com>

They are the same. In python 3.3 distutils2 is called packaging.

http://stackoverflow.com/questions/6344076/differences-between-distribute-distutils-and-setuptools

Daniel Holth

On May 19, 2012, at 12:49 AM, Rob Healey <robhealey1 at gmail.com> wrote:

> Hello once agai:
> 
> Is packaging in Python-3.3.0 a more complete software than DU2???  If it is, then I will start using it instead...?
> 
> -- 
> Sincerely yours,
> Rob G. Healey
> 
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

From tarek at ziade.org  Mon May 21 22:42:56 2012
From: tarek at ziade.org (=?UTF-8?B?VGFyZWsgWmlhZMOp?=)
Date: Mon, 21 May 2012 22:42:56 +0200
Subject: [Distutils] command hooks...
In-Reply-To: <4FB3E546.5090500@stsci.edu>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34ABE.5050108@ziade.org> <4FB3E546.5090500@stsci.edu>
Message-ID: <4FBAA8D0.50404@ziade.org>

On 5/16/12 7:35 PM, Mark Sienkiewicz wrote:
>
>
>> Can you see packaging as a set of utility at this point, rather than 
>> a tool that's going to replace instantly all the legacy tools ?
>
> If it is not going to replace the legacy tools, then why should I use it?

Who are you ?

If you are a user that just installs software, you might want to use it 
because you can *uninstall* things. This is now less relevant now that 
pip has this feature, but easy_install does not. And with the PEP we 
wrote, any tool should be able to install/uninstall any project. And 
well, have this feature bundled into Python makes sense.

If you are a packager for a project, you can describe in details your 
data files, and add more metadata that are understood by PyPI.

If you are a debian packager, you will be able to define where the data 
files of a python project should be installed without having to patch 
some python code.

I have much more but it's a bit hard to summarize this in a mail - I 
have a packaging fatigue anyways.

>
> My understanding is that the legacy tools already work, for some vague 
> definition of "work".  Your task is to convince me that "packaging" is 
> better -- which I think will be hard to do if packaging is not better.
It really depends what you put behind the word "better". And no, My task 
is not to convince you that packaging is better.

My tasks were :

1 - try to define standards which every packaging tool can implement, 
for the sake of interoperability, have a consensus on them, have them 
"accepted"
2 - allow more "static" definitions of metadata
3 - add in the standard library
   a/ a reference implementation for all the standards
   b/ a minimal installer.

3-b is not ready for prime time obviously - but this should not take too 
long.


Cheers
Tarek



> Mark S.
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


From tarek at ziade.org  Mon May 21 22:59:20 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 21 May 2012 22:59:20 +0200
Subject: [Distutils] command hooks...
In-Reply-To: <4FB3D519.1000009@plope.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
Message-ID: <4FBAACA8.9010108@ziade.org>

On 5/16/12 6:26 PM, Chris McDonough wrote:
> On 05/16/2012 02:55 AM, Tarek Ziad? wrote:
>> On 5/16/12 3:58 AM, Chris McDonough wrote:
>>> Adding two more (packaging and distutils2) which are similarly
>>> semi-documented and which don't even solve the problems that the
>>> previous ones do would serve no purpose, and baking them into Python
>>> itself will mean they can't evolve in important ways.
>>
>> Oh, I think I need to answer to this too since you said you wanted to
>> help. Packaging is not intended to be similar to setuptools in its
>> features.
>>
>> For instance we won't provide console scripts or entry points. The first
>> one because 'script' is the same feature (except there's an indirection
>> and I said before we could mimic this)
>> The second one because we should build this kind of feature outside the
>> stdlib (this is not something most people use, according to the survey I
>> did back a few years ago, it's mostly zope/plone/repoze land)
>
> I suspect many people don't really know they're using entry points 
> when they are. PasteDeploy configuration files rely heavily on entry 
> points.  Those are used in various ways by Pylons, Pyramid, Zope, and 
> Turbogears.  (PasteDeploy itself been downloaded almost a million 
> times from PyPI.)

yes.

on a side note: The PyPI stats numbers are biased for many libraries 
because they are artificially increased by all the buildouts and Jenkins 
and Travis-CI calls out there.
IOW: if a server downloads 100 times a day "PasteDeploy" because someone 
did not set a cache, does it make it 100 times more popular ?
Same goes for any library that's a core part of the non-monolithic 
frameworks out there.


>
> I'm fine with needing to depend on an external package to scan for 
> entrypoint-like-things registered as the result of the installation of 
> a distribution.  But there will need to be a way to register 
> entrypoint-like things (along the lines of arbitrary egg-info 
> metadata) as the result of distribution installation using pysetup.  
> Maybe that already exists.
we want to make the dist-info  (see PEP 376) structure a directory where 
you can drop anything, so you can have arbitrary metadata. Right now, 
entry_points.txt is copied over in that directory by pysetup.

the new setup.cfg file allows you to define extra metadata as well, and 
what's awesome: we want to publish that static file to PyPI so tools can 
browse it !

=> http://docs.python.org/dev/packaging/setupcfg.html#extensibility

>> IOW: packaging should only be the common basis and provide a basic
>> installer - not a full fledge tool you can use to replace the most
>> advanced setuptools features. And we want it pluggable enough so people
>> can build pluggable features on the top of it, like Eric explained 
>> earlier
>>
>> Does that make sense ?
>
> I'd like to say it does, but I'm afraid it does not.
>
> I can see shipping both machinery and a full-fledged installer that 
> handles all the use cases of existing installers.  I can also see 
> shipping just machinery and no installer at all.
>
> But I can't really see shipping both machinery and an installer that 
> we know doesn't service use cases that existing installers already 
> do.  At least I can't see doing that in order to service an external 
> shipping deadline. 

So what about this suggestion:

let's make this goal : pysetup should be able to install Pyramid 
(without [extras] sorry, we can live without it) - with a few 
adaptations in a branch if needed.

if we can make it work before 3.3rc1, great. If we fail we remove the 
installer part of packaging and move it to an external project

That's just a suggestion, I'll defer the decision to Eric because while 
I can help around, I don't have the time, neither the motivation to do 
packaging work these days.

But we have to hurry up - and check with Guido if he's ok with those 
decisions.

Cheers
Tarek

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


From erik.m.bray at gmail.com  Tue May 22 14:58:48 2012
From: erik.m.bray at gmail.com (Erik Bray)
Date: Tue, 22 May 2012 08:58:48 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FBAA8D0.50404@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34ABE.5050108@ziade.org> <4FB3E546.5090500@stsci.edu>
	<4FBAA8D0.50404@ziade.org>
Message-ID: <CAOTD34Y-Qo=zMNiw6DBFm9qKieBqXgDYLy694yT-NWECThRRhQ@mail.gmail.com>

On Mon, May 21, 2012 at 4:42 PM, Tarek Ziad? <tarek at ziade.org> wrote:
>> My understanding is that the legacy tools already work, for some vague
>> definition of "work". ?Your task is to convince me that "packaging" is
>> better -- which I think will be hard to do if packaging is not better.
>
> It really depends what you put behind the word "better". And no, My task is
> not to convince you that packaging is better.
>
> My tasks were :
>
> 1 - try to define standards which every packaging tool can implement, for
> the sake of interoperability, have a consensus on them, have them "accepted"
> 2 - allow more "static" definitions of metadata
> 3 - add in the standard library
> ?a/ a reference implementation for all the standards
> ?b/ a minimal installer.
>
> 3-b is not ready for prime time obviously - but this should not take too
> long.

I don't usually do this, and I think most people on this list are
already aware of it, but this seems like a decent place to insert a
shameless plug for d2to1 [1].  d2to1 allows Python developers to take
advantage of many of the features and advantages of packaging
today--in particular static metadata and hook functions--while still
supporting existing installers like easy_install and pip.  It's a
total hack, and only meant to aid with transition, but it actually
works quite well in practice.

Unfortunately I haven't found the time to work on it in a little while
so I need to find that time.  In particular it would be useful for it
to add resources support.

Erik

[1] http://pypi.python.org/pypi/d2to1

From rbpark at exolucere.ca  Wed May 23 08:16:01 2012
From: rbpark at exolucere.ca (Robert Park)
Date: Wed, 23 May 2012 01:16:01 -0500
Subject: [Distutils] command hooks...
In-Reply-To: <4FBAA8D0.50404@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34ABE.5050108@ziade.org> <4FB3E546.5090500@stsci.edu>
	<4FBAA8D0.50404@ziade.org>
Message-ID: <CAL3PwKwyYV7BTy7sCoKUje8s0yqMWt=zGZ0ytfGDBDeyf-N3Ww@mail.gmail.com>

On Mon, May 21, 2012 at 3:42 PM, Tarek Ziad? <tarek at ziade.org> wrote:
> If you are a packager for a project, you can describe in details your data
> files, and add more metadata that are understood by PyPI.
>
> If you are a debian packager, you will be able to define where the data
> files of a python project should be installed without having to patch some
> python code.

This right here is the killer feature for me. By my limited
observations, most people solve the data files problem either by
dumping their data files inside their python modules (which is an ugly
abuse of the filesystem), or are simply using the cumbersome autotools
in order to record the installation prefix for their data files. It
blows my mind that it is standard practice for many GNOME apps written
in Python to use a C compilation preprocessor in order to set a python
variable so their python scripts can find their data files.

Currently I am hacking distutils in order to accomplish this, like so:

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

But this is ugly because it modifies the file in-place, so I always
have to be careful not to accidentally commit the munged file into my
git repo.

It's absolutely critical that any replacement for distutils have
built-in functionality for installed python code being able to query
at run-time the location that data files were placed at install time.

-- 
http://exolucere.ca

From tarek at ziade.org  Wed May 23 08:48:27 2012
From: tarek at ziade.org (=?UTF-8?B?VGFyZWsgWmlhZMOp?=)
Date: Wed, 23 May 2012 08:48:27 +0200
Subject: [Distutils] command hooks...
In-Reply-To: <CAL3PwKwyYV7BTy7sCoKUje8s0yqMWt=zGZ0ytfGDBDeyf-N3Ww@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34ABE.5050108@ziade.org> <4FB3E546.5090500@stsci.edu>
	<4FBAA8D0.50404@ziade.org>
	<CAL3PwKwyYV7BTy7sCoKUje8s0yqMWt=zGZ0ytfGDBDeyf-N3Ww@mail.gmail.com>
Message-ID: <4FBC883B.6020609@ziade.org>

On 5/23/12 8:16 AM, Robert Park wrote:
> On Mon, May 21, 2012 at 3:42 PM, Tarek Ziad?<tarek at ziade.org>  wrote:
>> If you are a packager for a project, you can describe in details your data
>> files, and add more metadata that are understood by PyPI.
>>
>> If you are a debian packager, you will be able to define where the data
>> files of a python project should be installed without having to patch some
>> python code.
> This right here is the killer feature for me. By my limited
> observations, most people solve the data files problem either by
> dumping their data files inside their python modules (which is an ugly
> abuse of the filesystem), or are simply using the cumbersome autotools
> in order to record the installation prefix for their data files. It
> blows my mind that it is standard practice for many GNOME apps written
> in Python to use a C compilation preprocessor in order to set a python
> variable so their python scripts can find their data files.
>
> Currently I am hacking distutils in order to accomplish this, like so:
>
> https://github.com/robru/gottengeography/blob/master/setup.py
>
> But this is ugly because it modifies the file in-place, so I always
> have to be careful not to accidentally commit the munged file into my
> git repo.
>
> It's absolutely critical that any replacement for distutils have
> built-in functionality for installed python code being able to query
> at run-time the location that data files were placed at install time.
>
Please read this section and let us know what you think:

http://docs.python.org/dev/packaging/setupcfg.html#resources

This works in conjunction with the new sysconfig module, which can be 
configured system-wide by the linux distribution, or locally per projet

Then you can use an API to get the file from your code.

Gosh the documentation is a mess ... we need to fix this - it has bits 
from the previous version that should be removed :(

Cheers
Tarek

From oscar.j.benjamin at gmail.com  Wed May 23 13:50:54 2012
From: oscar.j.benjamin at gmail.com (Oscar Benjamin)
Date: Wed, 23 May 2012 12:50:54 +0100
Subject: [Distutils]  command hooks...
In-Reply-To: <CAHVvXxR9S4WvX8dEACA_HxpakfSRhFwLFw76LgBTams1SH0stA@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34ABE.5050108@ziade.org> <4FB3E546.5090500@stsci.edu>
	<4FBAA8D0.50404@ziade.org>
	<CAL3PwKwyYV7BTy7sCoKUje8s0yqMWt=zGZ0ytfGDBDeyf-N3Ww@mail.gmail.com>
	<4FBC883B.6020609@ziade.org>
	<CAHVvXxR9S4WvX8dEACA_HxpakfSRhFwLFw76LgBTams1SH0stA@mail.gmail.com>
Message-ID: <CAHVvXxSc994=y1SwwuJ6hEmKBE5R2uDrXnT+_kcALaUHg0txNQ@mail.gmail.com>

On 23 May 2012 07:48, Tarek Ziad? <tarek at ziade.org> wrote:

> On 5/23/12 8:16 AM, Robert Park wrote:
>
>> On Mon, May 21, 2012 at 3:42 PM, Tarek Ziad?<tarek at ziade.org>  wrote:
>>
>>> If you are a packager for a project, you can describe in details your
>>> data
>>> files, and add more metadata that are understood by PyPI.
>>>
>>> If you are a debian packager, you will be able to define where the data
>>> files of a python project should be installed without having to patch
>>> some
>>> python code.
>>>
>> This right here is the killer feature for me. By my limited
>> observations, most people solve the data files problem either by
>> dumping their data files inside their python modules (which is an ugly
>> abuse of the filesystem), or are simply using the cumbersome autotools
>> in order to record the installation prefix for their data files. It
>> blows my mind that it is standard practice for many GNOME apps written
>> in Python to use a C compilation preprocessor in order to set a python
>> variable so their python scripts can find their data files.
>>
>> Currently I am hacking distutils in order to accomplish this, like so:
>>
>> https://github.com/robru/**gottengeography/blob/master/**setup.py<https://github.com/robru/gottengeography/blob/master/setup.py>
>>
>> But this is ugly because it modifies the file in-place, so I always
>> have to be careful not to accidentally commit the munged file into my
>> git repo.
>>
>> It's absolutely critical that any replacement for distutils have
>> built-in functionality for installed python code being able to query
>> at run-time the location that data files were placed at install time.
>>
>>  Please read this section and let us know what you think:
>
> http://docs.python.org/dev/**packaging/setupcfg.html#**resources<http://docs.python.org/dev/packaging/setupcfg.html#resources>


How do gettext translation files fit into this scheme? Should they go under
appdata?


>
>
> This works in conjunction with the new sysconfig module, which can be
> configured system-wide by the linux distribution, or locally per projet
>
> Then you can use an API to get the file from your code.
>
> Gosh the documentation is a mess ... we need to fix this - it has bits
> from the previous version that should be removed :(
>
> Cheers
> Tarek
>
> ______________________________**_________________
> 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/20120523/5102fa68/attachment.html>

From rbpark at exolucere.ca  Wed May 23 18:27:02 2012
From: rbpark at exolucere.ca (Robert Park)
Date: Wed, 23 May 2012 11:27:02 -0500
Subject: [Distutils] command hooks...
In-Reply-To: <4FBC883B.6020609@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34ABE.5050108@ziade.org> <4FB3E546.5090500@stsci.edu>
	<4FBAA8D0.50404@ziade.org>
	<CAL3PwKwyYV7BTy7sCoKUje8s0yqMWt=zGZ0ytfGDBDeyf-N3Ww@mail.gmail.com>
	<4FBC883B.6020609@ziade.org>
Message-ID: <CAL3PwKwf3Au8KzdVgd=mqtAGPLW5VkBCX5ooNexC-tEZtNBy9w@mail.gmail.com>

On Wed, May 23, 2012 at 1:48 AM, Tarek Ziad? <tarek at ziade.org> wrote:
> On 5/23/12 8:16 AM, Robert Park wrote:
>> It's absolutely critical that any replacement for distutils have
>> built-in functionality for installed python code being able to query
>> at run-time the location that data files were placed at install time.
>
> Please read this section and let us know what you think:
>
> http://docs.python.org/dev/packaging/setupcfg.html#resources

Yeah, the [files] definition in setup.cfg looks fine, the space syntax
in the source definition I would consider highly important in order to
avoid installing things into {datadir}/doc/foo/doc/ as given in the
example.

> This works in conjunction with the new sysconfig module, which can be
> configured system-wide by the linux distribution, or locally per projet
>
> Then you can use an API to get the file from your code.

I didn't see any mention of this aspect in the documentation you
linked. What does the API look like?

-- 
http://exolucere.ca

From dholth at gmail.com  Wed May 23 19:12:56 2012
From: dholth at gmail.com (Daniel Holth)
Date: Wed, 23 May 2012 13:12:56 -0400
Subject: [Distutils] pypm binary package format
Message-ID: <CAG8k2+4QnwQmXpNSnhfHhoFYr71iE2qcsTgfY63eh=UcKVEGMA@mail.gmail.com>

I was curious about the pypm binary package format. They are in the
.tar.gz format (but with .pypm extension). They contain two files:

info.json:

{u'author': u'Zope Foundation and Contributors',
 u'author_email': u'zope-dev at zope.org',
 u'description': '...',
 u'home_page': u'http://pypi.python.org/pypi/zope.interface',
 u'install_requires': {u'': [u'distribute'],
                       u'docs': [u'z3c.recipe.sphinxdoc'],
                       u'test': [u'zope.event']},
 u'keywords': None,
 u'license': u'ZPL 2.1',
 u'maintainer': None,
 u'maintainer_email': None,
 u'name': u'zope.interface',
 u'osarch': u'win32-x86',
 u'pkg_version': 1,
 u'pyver': u'2.7',
 u'summary': u'Interfaces for Python',
 u'version': u'3.8.0'}

data.tar.gz:

Lib/site-packages/zope.interface/... (including .pyd or .so)
Lib/site-packages/zope.interface-3.8.0-py27.egg-info/(normal egg-info stuff)

When installed, Lib/ is unpacked into %APPDATA%\Python\Python27\site-packages\

From chrism at plope.com  Thu May 24 05:59:48 2012
From: chrism at plope.com (Chris McDonough)
Date: Wed, 23 May 2012 23:59:48 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FBAACA8.9010108@ziade.org>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org>
Message-ID: <4FBDB234.5080805@plope.com>

On 05/21/2012 04:59 PM, Tarek Ziad? wrote:
> On 5/16/12 6:26 PM, Chris McDonough wrote:
>> On 05/16/2012 02:55 AM, Tarek Ziad? wrote:
>>> On 5/16/12 3:58 AM, Chris McDonough wrote:
>>>> Adding two more (packaging and distutils2) which are similarly
>>>> semi-documented and which don't even solve the problems that the
>>>> previous ones do would serve no purpose, and baking them into Python
>>>> itself will mean they can't evolve in important ways.
>>>
>>> Oh, I think I need to answer to this too since you said you wanted to
>>> help. Packaging is not intended to be similar to setuptools in its
>>> features.
>>>
>>> For instance we won't provide console scripts or entry points. The first
>>> one because 'script' is the same feature (except there's an indirection
>>> and I said before we could mimic this)
>>> The second one because we should build this kind of feature outside the
>>> stdlib (this is not something most people use, according to the survey I
>>> did back a few years ago, it's mostly zope/plone/repoze land)
>>
>> I suspect many people don't really know they're using entry points
>> when they are. PasteDeploy configuration files rely heavily on entry
>> points. Those are used in various ways by Pylons, Pyramid, Zope, and
>> Turbogears. (PasteDeploy itself been downloaded almost a million times
>> from PyPI.)
>
> yes.
>
> on a side note: The PyPI stats numbers are biased for many libraries
> because they are artificially increased by all the buildouts and Jenkins
> and Travis-CI calls out there.
> IOW: if a server downloads 100 times a day "PasteDeploy" because someone
> did not set a cache, does it make it 100 times more popular ?
> Same goes for any library that's a core part of the non-monolithic
> frameworks out there.
>
>
>>
>> I'm fine with needing to depend on an external package to scan for
>> entrypoint-like-things registered as the result of the installation of
>> a distribution. But there will need to be a way to register
>> entrypoint-like things (along the lines of arbitrary egg-info
>> metadata) as the result of distribution installation using pysetup.
>> Maybe that already exists.
> we want to make the dist-info (see PEP 376) structure a directory where
> you can drop anything, so you can have arbitrary metadata. Right now,
> entry_points.txt is copied over in that directory by pysetup.
>
> the new setup.cfg file allows you to define extra metadata as well, and
> what's awesome: we want to publish that static file to PyPI so tools can
> browse it !
>
> => http://docs.python.org/dev/packaging/setupcfg.html#extensibility
>
>>> IOW: packaging should only be the common basis and provide a basic
>>> installer - not a full fledge tool you can use to replace the most
>>> advanced setuptools features. And we want it pluggable enough so people
>>> can build pluggable features on the top of it, like Eric explained
>>> earlier
>>>
>>> Does that make sense ?
>>
>> I'd like to say it does, but I'm afraid it does not.
>>
>> I can see shipping both machinery and a full-fledged installer that
>> handles all the use cases of existing installers. I can also see
>> shipping just machinery and no installer at all.
>>
>> But I can't really see shipping both machinery and an installer that
>> we know doesn't service use cases that existing installers already do.
>> At least I can't see doing that in order to service an external
>> shipping deadline.
>
> So what about this suggestion:
>
> let's make this goal : pysetup should be able to install Pyramid
> (without [extras] sorry, we can live without it) - with a few
> adaptations in a branch if needed.
>
> if we can make it work before 3.3rc1, great. If we fail we remove the
> installer part of packaging and move it to an external project
>
> That's just a suggestion, I'll defer the decision to Eric because while
> I can help around, I don't have the time, neither the motivation to do
> packaging work these days.
>
> But we have to hurry up - and check with Guido if he's ok with those
> decisions.

It sounds like a reasonable task for me to try out.  In the meantime 
we've had a bit of a family emergency which will take some time to 
overcome and I won't be able to dedicate much energy to this.  As a 
result, I have to declare bankruptcy here, so I'll have to live with 
whatever I get.

I'm hoping though that someone else will step up here and do an 
evaluation and try to get things like Pyramid and popular Zope packages 
installed in a way that makes sense for straddling Python 2 and Python 
3.  I suspect if no one does this, it's going to be rough going.

- C

From erik.m.bray at gmail.com  Thu May 24 23:37:14 2012
From: erik.m.bray at gmail.com (Erik Bray)
Date: Thu, 24 May 2012 17:37:14 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FBDB234.5080805@plope.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
Message-ID: <CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>

On Wed, May 23, 2012 at 11:59 PM, Chris McDonough <chrism at plope.com> wrote:
> It sounds like a reasonable task for me to try out. ?In the meantime we've
> had a bit of a family emergency which will take some time to overcome and I
> won't be able to dedicate much energy to this. ?As a result, I have to
> declare bankruptcy here, so I'll have to live with whatever I get.

Sorry to hear about that.

> I'm hoping though that someone else will step up here and do an evaluation
> and try to get things like Pyramid and popular Zope packages installed in a
> way that makes sense for straddling Python 2 and Python 3. ?I suspect if no
> one does this, it's going to be rough going.
>
>
> - C

For something like Pyramid I don't actually think it would be too
difficult to get it *mostly* working with packaging/distutils2 in its
present state.  The word is "mostly".  And that's to say nothing of
all its dependencies, though they don't all necessarily need to work
with the same installer.

For something like Pyramid the main piece that's missing is support
for an entry_points like system.  As Tarek and other have pointed out
the past, such a system could still be supported through a third-party
plugin system that works via setup hooks and custom metadata.  I think
there was even a prototype for something like that at one point...

But that raises another issue:  If packaging is going to be like a
"framework" that additional features like plugin systems or console
script generators can be tacked on to, there needs to be a way to
specify build dependencies in setup.cfg, and to have those
dependencies automatically downloaded and added to sys.path during
setup, a la setup_requires in setuptools.

I know there have been discussions and proposals in the past to add
something like this to packaging, and to amend PEP 345 to include it.
Metadata for test dependencies and docs dependencies have also been
discussed in the past.  But I think a way of adding build/setup
dependencies is critical if packaging is going to be useful as a
framework.

I have a few packages that use d2to1, which supports setup_requires
through setuptools.  Thanks to that, I'm able to make those packages
have an additional setup_requirement of a package that contains
several pre-canned setup_hooks that I use in all my projects.  I would
point out specific examples, but they're a bit obscure...

Anyways, I'm working right now to finish a software release.  But then
I want to spend some time working on this issue of adding build
requirements support to packaging and to PEP 345.  I might also work
on a plugin system that can work in packaging as a replacement for
entry_points, if no one else does.  Without these features I don't see
packaging being very successful as an installation framework, IMO.

Erik

From dholth at gmail.com  Fri May 25 00:56:12 2012
From: dholth at gmail.com (Daniel Holth)
Date: Thu, 24 May 2012 18:56:12 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
Message-ID: <CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>

> For something like Pyramid the main piece that's missing is support
> for an entry_points like system. ?As Tarek and other have pointed out
> the past, such a system could still be supported through a third-party
> plugin system that works via setup hooks and custom metadata. ?I think
> there was even a prototype for something like that at one point...

'packaging' will be powerful enough to copy entry_points.txt into the
.dist-info directory as a resource. Python bug #11880.

The existing entry points code has a plugin mechanism for itself that
will make it easy to iterate over entry_points.txt in dist-info as
well as egg-info directories. Just write that plugin and you should be
good to go. Though you might have to install the plugin in an egg-info
directory at first...

From pje at telecommunity.com  Fri May 25 02:27:39 2012
From: pje at telecommunity.com (PJ Eby)
Date: Thu, 24 May 2012 20:27:39 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
Message-ID: <CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>

On Thu, May 24, 2012 at 6:56 PM, Daniel Holth <dholth at gmail.com> wrote:

> > For something like Pyramid the main piece that's missing is support
> > for an entry_points like system.  As Tarek and other have pointed out
> > the past, such a system could still be supported through a third-party
> > plugin system that works via setup hooks and custom metadata.  I think
> > there was even a prototype for something like that at one point...
>
> 'packaging' will be powerful enough to copy entry_points.txt into the
> .dist-info directory as a resource. Python bug #11880.
>
> The existing entry points code has a plugin mechanism for itself that
> will make it easy to iterate over entry_points.txt in dist-info as
> well as egg-info directories. Just write that plugin and you should be
> good to go. Though you might have to install the plugin in an egg-info
> directory at first...
>

What plugin mechanism are you talking about here, specifically?

For that matter, which "existing entry points code" are you talking about,
too?  ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120524/0b25f73e/attachment.html>

From dholth at gmail.com  Fri May 25 02:48:40 2012
From: dholth at gmail.com (Daniel Holth)
Date: Thu, 24 May 2012 20:48:40 -0400
Subject: [Distutils] entry_points.txt survey
Message-ID: <CAG8k2+7u8VGMU2woO_50cXQw4f_yZ+x33fbbJxV66wwZA_-dxA@mail.gmail.com>

It looks like you can call pkg_resources.register_finder() with a
function that also yields distributions with a .dist-info directory
(though you would have to override the existing find_on_path). From
there I think pkg_resources.load_entry_point() is likely to work.

>From a survey of 16984 pypi source distributions (the newest for each
package surveyed), 5878 define entry_points.txt but 1399 of those are
empty. Some of the most popular sections are:

 (10, 'babel.extractors'),
 (10, 'lava_server.extensions'),
 (10, 'paste.composite_factory'),
 (10, 'turbogears.extensions'),
 (10, 'yafowil.plugin'),
 (10, 'zest.releaser.prereleaser.middle'),
 (11, 'chandler.parcels'),
 (11, 'rsl.register'),
 (12, 'hurry.resource.libraries'),
 (15, 'paste.global_paster_command'),
 (16, 'pyramid.scaffold'),
 (17, 'zc.buildout.uninstall'),
 (18, 'paste.server_runner'),
 (18, 'setuptools.installation'),
 (19, 'python.templating.engines'),
 (20, 'redsolutioncms'),
 (20, 'zope2.initialize'),
 (22, 'pytest11'),
 (23, 'setuptools.file_finders'),
 (26, 'paste.paster_command'),
 (30, 'nose.plugins'),
 (31, 'paste.filter_factory'),
 (31, 'zc.buildout.extension'),
 (35, 'toscawidgets.widgets'),
 (35, 'turbogears.widgets'),
 (37, 'tw2.widgets'),
 (47, 'paste.app_install'),
 (69, 'nose.plugins.0.10'),
 (73, 'distutils.commands'),
 (81, 'trytond.modules'),
 (82, 'gui_scripts'),
 (83, 'paste.filter_app_factory'),
 (94, 'fanstatic.libraries'),
 (96, 'trac.plugins'),
 (110, 'egg_info.writers'),
 (120, 'distutils.setup_keywords'),
 (144, 'paste.paster_create_template'),
 (190, 'paste.app_factory'),
 (354, 'zc.buildout'),
 (1004, 'z3c.autoinclude.plugin'),
 (1754, 'console_scripts')

From pje at telecommunity.com  Fri May 25 05:40:05 2012
From: pje at telecommunity.com (PJ Eby)
Date: Thu, 24 May 2012 23:40:05 -0400
Subject: [Distutils] entry_points.txt survey
In-Reply-To: <CAG8k2+7u8VGMU2woO_50cXQw4f_yZ+x33fbbJxV66wwZA_-dxA@mail.gmail.com>
References: <CAG8k2+7u8VGMU2woO_50cXQw4f_yZ+x33fbbJxV66wwZA_-dxA@mail.gmail.com>
Message-ID: <CALeMXf7nSZzc+XkQNmJxv3JUmZ_bkAt35X14HyF=JxzQ7Jxsfg@mail.gmail.com>

On Thu, May 24, 2012 at 8:48 PM, Daniel Holth <dholth at gmail.com> wrote:

> It looks like you can call pkg_resources.register_finder() with a
>

Ah, *that* plugin facility.  I thought you were talking about something
specific to entry points (a mechanism which doesn't exist, at least in
setuptools), vs. implementing your own metadata/resource handlers for a
specific distribution type.  (Which is an intended extensibility mechanism
for specialized importer metadata in general.)


> function that also yields distributions with a .dist-info directory
> (though you would have to override the existing find_on_path). From
> there I think pkg_resources.load_entry_point() is likely to work.
>

Yes, you would need to implement a metadata handler (probably subclassing
PathMetadata) for your finder to provide, and you'd need to delegate to the
existing find_on_path().  Your metadata handler would need to translate
requests for PKG-INFO and other setuptools metadata, so it would need to
override get_metadata().

I was planning to do something like this in setuptools eventually, but as
you point out, it's quite possible to do it in a separate piece of code,
albeit some rather monkeypatching-like code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120524/8dfa517f/attachment-0001.html>

From erik.m.bray at gmail.com  Fri May 25 19:46:23 2012
From: erik.m.bray at gmail.com (Erik Bray)
Date: Fri, 25 May 2012 13:46:23 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
Message-ID: <CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>

On Thu, May 24, 2012 at 8:27 PM, PJ Eby <pje at telecommunity.com> wrote:
> On Thu, May 24, 2012 at 6:56 PM, Daniel Holth <dholth at gmail.com> wrote:
>>
>> > For something like Pyramid the main piece that's missing is support
>> > for an entry_points like system. ?As Tarek and other have pointed out
>> > the past, such a system could still be supported through a third-party
>> > plugin system that works via setup hooks and custom metadata. ?I think
>> > there was even a prototype for something like that at one point...
>>
>> 'packaging' will be powerful enough to copy entry_points.txt into the
>> .dist-info directory as a resource. Python bug #11880.
>>
>> The existing entry points code has a plugin mechanism for itself that
>> will make it easy to iterate over entry_points.txt in dist-info as
>> well as egg-info directories. Just write that plugin and you should be
>> good to go. Though you might have to install the plugin in an egg-info
>> directory at first...
>
>
> What plugin mechanism are you talking about here, specifically?
>
> For that matter, which "existing entry points code" are you talking about,
> too?? ;-)

Yeah, I'm a little confused by this too.  Sure you could include an
entry_points.txt in the dist-info. Though it's not clear to me that
there's an entirely straightforward way to do this yet.  I think some
ideas have been tossed about for how to make it easier to include
custom files in dist-info, but that there were no conclusions on that.
 Or maybe it already is easy and I'm just missing something.

Then there would need to be some interface like
pkg_resources.iter_entry_points() available to all software that
relies on entry_points.  This could be provided by the same plugin
that adds entry_points.txt to dist-info.  That plugin would have to be
an installation requirement for any software that relies on it (as is
setuptools for any package that currently uses entry_points, so I
don't think that's such a hardship...)

Erik

From dholth at gmail.com  Fri May 25 20:24:49 2012
From: dholth at gmail.com (Daniel Holth)
Date: Fri, 25 May 2012 14:24:49 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
Message-ID: <CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>

This discussion is confusing because we are either talking about a
general plugin discovery mechanism for Python, or a plugin mechanism
that packaging itself uses.

After the patch, entry_points.txt (which you are encouraged to write
yourself) is copied by means of a new {dist-info} category using the
resources = mechanism in packaging. This is a straightforward way to
copy anything into the .dist-info directory. Apart from copying the
file, 'packaging' has no role.

setup.cfg:

[files]
packages = mypackage
resources =
    entry_points.txt={dist-info}

That's all there is to it.

From erik.m.bray at gmail.com  Fri May 25 22:23:09 2012
From: erik.m.bray at gmail.com (Erik Bray)
Date: Fri, 25 May 2012 16:23:09 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
	<CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
Message-ID: <CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>

On Fri, May 25, 2012 at 2:24 PM, Daniel Holth <dholth at gmail.com> wrote:
> This discussion is confusing because we are either talking about a
> general plugin discovery mechanism for Python, or a plugin mechanism
> that packaging itself uses.
>
> After the patch, entry_points.txt (which you are encouraged to write
> yourself) is copied by means of a new {dist-info} category using the
> resources = mechanism in packaging. This is a straightforward way to
> copy anything into the .dist-info directory. Apart from copying the
> file, 'packaging' has no role.
>
> setup.cfg:
>
> [files]
> packages = mypackage
> resources =
> ? ?entry_points.txt={dist-info}
>
> That's all there is to it.

Neat! I didn't realize there was a {dist-info} resource category.
That, plus the register_finder() approach mentioned in the other
thread could be a way to go for interoperability with packages using
setuptools.  It would still require a bit of hackery though...  I
suspect there would be resistance to adding support for this directly
in packaging.  But a setup_hook could set this up.

Erik

From todddeluca at gmail.com  Sun May 27 17:19:18 2012
From: todddeluca at gmail.com (Todd DeLuca)
Date: Sun, 27 May 2012 11:19:18 -0400
Subject: [Distutils] Distutils2: Does uploading to pypi work yet?
Message-ID: <CAJRoPYZfeymyMpZ2_-sUbfx5nCnTTqqtFEoqiHNWkN21BMLo-g@mail.gmail.com>

I recently failed to upload a project to pypi using distutils2 and failed
to install the project using pip.  Are distutils2 and pip not yet
supporting 'setup.cfg' only projects yet?

The upload failed to upload the tarball to pypi because of what looks like
a problem encoding a multipart form message with
distutils2.util.encode_multipart(). I tried to fix that problem (using a
base64 encoding) but ran into 500 http return code from the pypi server.
The uploading code seems pretty 'alpha', so I was wondering if anyone is
successfully using 'pysetup' to upload projects to pypi.

After failing to upload the distribtion, I uploaded it to github and then
registered my project with a github download url.  Then I tried installing
my project using pip and that failed too, since I did not have a setup.py,
only a setup.cfg, in the project.

I'm using python 2.7.3, pip 1.1, and distutils2 from
hg.python.org/distutils2 (pulled and updated) on Mac OS X 10.6.8.


-- 
Todd DeLuca
http://todddeluca.com
http://wall.hms.harvard.edu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120527/04e7a864/attachment.html>

From donald.stufft at gmail.com  Sun May 27 17:20:29 2012
From: donald.stufft at gmail.com (Donald Stufft)
Date: Sun, 27 May 2012 11:20:29 -0400
Subject: [Distutils] Distutils2: Does uploading to pypi work yet?
In-Reply-To: <CAJRoPYZfeymyMpZ2_-sUbfx5nCnTTqqtFEoqiHNWkN21BMLo-g@mail.gmail.com>
References: <CAJRoPYZfeymyMpZ2_-sUbfx5nCnTTqqtFEoqiHNWkN21BMLo-g@mail.gmail.com>
Message-ID: <CECF7C63C57246659734988708BC60B9@gmail.com>

I can't speak for uploading to PyPI, but pip doesn't support distutils2 yet. 


On Sunday, May 27, 2012 at 11:19 AM, Todd DeLuca wrote:

> I recently failed to upload a project to pypi using distutils2 and failed to install the project using pip.  Are distutils2 and pip not yet supporting 'setup.cfg' only projects yet?
> 
> The upload failed to upload the tarball to pypi because of what looks like a problem encoding a multipart form message with distutils2.util.encode_multipart(). I tried to fix that problem (using a base64 encoding) but ran into 500 http return code from the pypi server.   The uploading code seems pretty 'alpha', so I was wondering if anyone is successfully using 'pysetup' to upload projects to pypi. 
> 
> After failing to upload the distribtion, I uploaded it to github and then registered my project with a github download url.  Then I tried installing my project using pip and that failed too, since I did not have a setup.py, only a setup.cfg, in the project. 
> 
> I'm using python 2.7.3, pip 1.1, and distutils2 from hg.python.org/distutils2 (http://hg.python.org/distutils2) (pulled and updated) on Mac OS X 10.6.8.
> 
> 
> -- 
> Todd DeLuca
> http://todddeluca.com
> http://wall.hms.harvard.edu/
> 
> 
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org (mailto:Distutils-SIG at python.org)
> http://mail.python.org/mailman/listinfo/distutils-sig
> 
> 


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

From pje at telecommunity.com  Sun May 27 18:33:05 2012
From: pje at telecommunity.com (PJ Eby)
Date: Sun, 27 May 2012 12:33:05 -0400
Subject: [Distutils] bin/buildout hoses itself when the buildout directory
	has a long path
Message-ID: <CALeMXf5f1Nv6bqBc5HzM7P5-cij-2siZPeH0_2xfi7c=Y0EsnA@mail.gmail.com>

AFAICT, this problem was only reported once, here:
https://mail.zope.org/pipermail/zope-dev/2012-February/044108.html but
nobody identified the cause or steps to reproduce.

What I've figured out is this: if your buildout's absolute path is
sufficiently long (I believe it's just if it's longer than your system
site-packages' absolute path), then running bin/buildout (vs. the system
buildout) will decide NOT to include eggs/zc.buildout in the buildout_paths
list in parts/buildout/site.py.  The result of this is that the zc.buildout
egg gets left out of pkg_resources.working_set, which means that when
buildout tries to find itself in the working set, it fails, resulting in
the following error:

$ bin/buildout
Upgraded:
  zc.buildout version 1.5.2;
restarting.
Traceback (most recent call last):
  File "bin/buildout", line 17, in <module>
    import zc.buildout.buildout
  File
"/usr/lib/python2.6/site-packages/zc.buildout-1.5.2-py2.6.egg/zc/buildout/buildout.py",
line 39, in <module>
    import zc.buildout.download
  File
"/usr/lib/python2.6/site-packages/zc.buildout-1.5.2-py2.6.egg/zc/buildout/download.py",
line 20, in <module>
    from zc.buildout.easy_install import realpath
  File
"/usr/lib/python2.6/site-packages/zc.buildout-1.5.2-py2.6.egg/zc/buildout/easy_install.py",
line 81, in <module>
    pkg_resources.Requirement.parse('zc.buildout')).location
AttributeError: 'NoneType' object has no attribute 'location'


Notice that the buildout is using the site-packages zc.buildout egg,
instead of the one in the local eggs directory.

Steps to reproduce:

$ cd really/really/long/directory/name/with/lots/of/stuff/emptydir
$ buildout init
$ bin/buildout

Workaround:  use "include-site-packages = false" in the [buildout] section.

This strongly suggests to me that some part of the site-packages isolation
mechanism is broken, at least for zc.buildout itself.  It is successfully
allowing zc.buildout to be imported from site-packages, but not letting
setuptools see that it is present in site-packages.  If it does this for
other packages that refer to themselves in the way zc.buildout.easy_install
does, they will similarly break.  (Likewise anything expecting to find
entry points, etc.)

On a somewhat unrelated note, I am as of yesterday a new zc.buildout
user...  and I already have a buildout that compiles Erlang, Spidermonkey,
CouchDB, and RabbitMQ, and sets them all up with a Celery daemon under
Supervisord, all in about 63 lines of .ini file.  To say that I am
impressed with buildout is an extreme understatement.  ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120527/ff9e8b7e/attachment.html>

From pje at telecommunity.com  Sun May 27 18:58:42 2012
From: pje at telecommunity.com (PJ Eby)
Date: Sun, 27 May 2012 12:58:42 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
	<CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
	<CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>
Message-ID: <CALeMXf73CjRkxNG20p8nyQAV78aTbU0MKZ2r5mPcXFsFQtvGCA@mail.gmail.com>

On Fri, May 25, 2012 at 4:23 PM, Erik Bray <erik.m.bray at gmail.com> wrote:

> On Fri, May 25, 2012 at 2:24 PM, Daniel Holth <dholth at gmail.com> wrote:
> > This discussion is confusing because we are either talking about a
> > general plugin discovery mechanism for Python, or a plugin mechanism
> > that packaging itself uses.
> >
> > After the patch, entry_points.txt (which you are encouraged to write
> > yourself) is copied by means of a new {dist-info} category using the
> > resources = mechanism in packaging. This is a straightforward way to
> > copy anything into the .dist-info directory. Apart from copying the
> > file, 'packaging' has no role.
> >
> > setup.cfg:
> >
> > [files]
> > packages = mypackage
> > resources =
> >    entry_points.txt={dist-info}
> >
> > That's all there is to it.
>
> Neat! I didn't realize there was a {dist-info} resource category.
> That, plus the register_finder() approach mentioned in the other
> thread could be a way to go for interoperability with packages using
> setuptools.  It would still require a bit of hackery though...  I
> suspect there would be resistance to adding support for this directly
> in packaging.  But a setup_hook could set this up.
>

Ideally, one should just be able to add sections to setup.cfg itself to
describe the entry points.  Better yet: just include setup.cfg in the
dist-info directory, and then the replacement for entry points can look for
arbitrary sections in setup.cfg files.  (The downside: slower first-use
performance, since every setup.cfg would have to be read at least once, but
on the upside, all subsequent entry point lookups would be faster.)

Is setup.cfg already in dist-info?  I guess if it isn't, you could just add
it, using the same mechanism above.  Hm....  (goes to look at packaging
docs)...  Ouch.  I'm seeing a bigger problem, which is that without either
the ability to do "setup_requires" or to ship an sdist with a hook-altered
setup.cfg, it doesn't look like you can actually implement all of
setuptools' build functionality with just packaging.  (e.g. Setuptools can
ship an sdist whose contents and version were determined using revision
control info, but which does not then require the revision control tool
when installing from the sdist, as the sdist contains a pre-built manifest,
and a pre-built setup.cfg with hardcoded version numbers copied from the
original revision control info.)

I really hope I'm not going to have to write setuptools2 to work around
these limitations.  ;-)   (Preferably, if I do write a setuptools2, I hope
it can all be done using proper setup hooks on top of packaging/distutils2,
without monkeypatching anything.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120527/7ff8b152/attachment-0001.html>

From cbrown1 at pitt.edu  Sun May 27 19:15:39 2012
From: cbrown1 at pitt.edu (Brown, Christopher)
Date: Sun, 27 May 2012 13:15:39 -0400
Subject: [Distutils] building a shared lib
Message-ID: <4FC2613B.3090208@pitt.edu>

Hi,

I am developing a Python package and use distutils. The package relies 
on a shared lib, for which the build process is slightly more than 
trivial. So, I have created a shell script to build the lib (lets call 
that buildlib.sh). Then, I have another script in the package root 
(buildpackage.sh) that first calls buildlib.sh, and the runs the 
setup.py script to build and/or install the package.

This works fine, but I would like to allow users to just run python 
setup.py build/install to simplify things for them. I can call 
buildlib.sh from within setup.py, but I am unsure of the right way to do 
it. Should I just call buildlib.sh everytime from setup.py, regardless 
of whether it is with 'build' or 'install'? Can I detect if 'build' is 
being run (whether from 'setup.py build' or 'setup.py install') and only 
run it then? Is there a better way to handle this?

Thanks!

-Chris

-- 
Christopher Brown, Ph.D.
Assistant Professor
Department of Communication Science and Disorders
University of Pittsburgh

From martin at v.loewis.de  Mon May 28 19:21:02 2012
From: martin at v.loewis.de (martin at v.loewis.de)
Date: Mon, 28 May 2012 19:21:02 +0200
Subject: [Distutils] building a shared lib
In-Reply-To: <4FC2613B.3090208@pitt.edu>
References: <4FC2613B.3090208@pitt.edu>
Message-ID: <20120528192102.Horde.9qaaJ9jz9kRPw7P_nRMznQA@webmail.df.eu>

> This works fine, but I would like to allow users to just run python
> setup.py build/install to simplify things for them. I can call
> buildlib.sh from within setup.py, but I am unsure of the right way to do
> it. Should I just call buildlib.sh everytime from setup.py, regardless
> of whether it is with 'build' or 'install'? Can I detect if 'build' is
> being run (whether from 'setup.py build' or 'setup.py install') and only
> run it then? Is there a better way to handle this?

You should create a sub-command of the build command. See commands/build.py,
and find the current list of subcommands of build. Create a new one,
and either monkey-patch build to include this subcommand, or subclass build,
and override it.

HTH,
Martin



From robhealey1 at gmail.com  Tue May 29 04:43:14 2012
From: robhealey1 at gmail.com (Rob Healey)
Date: Mon, 28 May 2012 19:43:14 -0700
Subject: [Distutils] DU2 1.0a5
Message-ID: <CAAq8ydtzvRhTKcofYD7swgodKu6fHkO34mBwXKJsprO8AcGEMw@mail.gmail.com>

Dear Eric:

Do you know when we might be expecting this version release after this last
sprint, you stated that it might be soon...

Do you know when the next sprint will be scheduled?

-- 
Sincerely yours,
Rob G. Healey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120528/baebee98/attachment.html>

From merwok at netwok.org  Tue May 29 05:28:16 2012
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 28 May 2012 23:28:16 -0400
Subject: [Distutils] DU2 1.0a5
In-Reply-To: <CAAq8ydtzvRhTKcofYD7swgodKu6fHkO34mBwXKJsprO8AcGEMw@mail.gmail.com>
References: <CAAq8ydtzvRhTKcofYD7swgodKu6fHkO34mBwXKJsprO8AcGEMw@mail.gmail.com>
Message-ID: <4FC44250.5000306@netwok.org>

Hi Rob,

I really can?t predict.  I could release a5 right now, but it only has a
couple fixes compared to a4; I would like to have some more significant
fixes, like the bytes/string I/O errors in the register command, or the
many bugs that show only on Windows fixed, or new features like the
develop command.

The next sprint is to be confirmed on the 9th.

Cheers

From robhealey1 at gmail.com  Tue May 29 06:04:49 2012
From: robhealey1 at gmail.com (Rob Healey)
Date: Mon, 28 May 2012 21:04:49 -0700
Subject: [Distutils] one project into several sub projects???
Message-ID: <CAAq8ydvFNGtWp9pnOSM=K8AbwdSV6Ofqajbpt3XmLmW8f3JcUQ@mail.gmail.com>

Greetings:

I would like to know what would be the best way to handle this situation???

I have a project that needs to be split into several smaller pieces/
projects:
1) core
2) gui
3) cli
4) web

Could you give me the best case scenario to split up this one project?  It
would be best if I used DU2 or Packaging...  I need something that will be
supported for as while to come...

Our project will be moving into Python3 compatibility...

-- 
Sincerely yours,
Rob G. Healey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120528/4e2b5aa6/attachment.html>

From techtonik at gmail.com  Tue May 29 07:55:51 2012
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 29 May 2012 08:55:51 +0300
Subject: [Distutils] `pysetup create`, but `pysetup run install_dist` - wtf?
Message-ID: <CAPkN8x+tW6GDpmX3-MaYJSb+hRLXc9S6K+TGT26V_nsyhnXO_g@mail.gmail.com>

Hi,

http://docs.python.org/dev/packaging/tutorial.html#running-commands
What's the point in using 'pysetup run install_dist' instead of just
'pysetup install' ??
--
anatoly t.

From alexis at notmyidea.org  Tue May 29 12:19:33 2012
From: alexis at notmyidea.org (=?UTF-8?B?QWxleGlzIE3DqXRhaXJlYXU=?=)
Date: Tue, 29 May 2012 12:19:33 +0200
Subject: [Distutils] `pysetup create`,
 but `pysetup run install_dist` - wtf?
In-Reply-To: <CAPkN8x+tW6GDpmX3-MaYJSb+hRLXc9S6K+TGT26V_nsyhnXO_g@mail.gmail.com>
References: <CAPkN8x+tW6GDpmX3-MaYJSb+hRLXc9S6K+TGT26V_nsyhnXO_g@mail.gmail.com>
Message-ID: <4FC4A2B5.7010201@notmyidea.org>

Le mar. 29 mai 2012 07:55:51 CEST, anatoly techtonik a ?crit :
> http://docs.python.org/dev/packaging/tutorial.html#running-commands
> What's the point in using 'pysetup run install_dist' instead of just
> 'pysetup install' ??

They are two different commands which aren't doing the same thing. One 
installs the distribution, without dealing with its dependencies (the 
install_dist command) while the other fetches and deals with the 
dependencies.

This probably should be stated more clearly in the tutorial, thanks for 
pointing this out.

From alexis at notmyidea.org  Tue May 29 12:23:26 2012
From: alexis at notmyidea.org (=?UTF-8?B?QWxleGlzIE3DqXRhaXJlYXU=?=)
Date: Tue, 29 May 2012 12:23:26 +0200
Subject: [Distutils] `pysetup create`,
 but `pysetup run install_dist` - wtf?
In-Reply-To: <4FC4A2B5.7010201@notmyidea.org>
References: <CAPkN8x+tW6GDpmX3-MaYJSb+hRLXc9S6K+TGT26V_nsyhnXO_g@mail.gmail.com>
	<4FC4A2B5.7010201@notmyidea.org>
Message-ID: <4FC4A39E.1040403@notmyidea.org>

Le mar. 29 mai 2012 12:19:33 CEST, Alexis M?taireau a ?crit :
> Le mar. 29 mai 2012 07:55:51 CEST, anatoly techtonik a ?crit :
>> http://docs.python.org/dev/packaging/tutorial.html#running-commands
>> What's the point in using 'pysetup run install_dist' instead of just
>> 'pysetup install' ??
>
> They are two different commands which aren't doing the same thing. One
> installs the distribution, without dealing with its dependencies (the
> install_dist command) while the other fetches and deals with the
> dependencies.
>
> This probably should be stated more clearly in the tutorial, thanks
> for pointing this out.

I just created a bug requesting this: 
http://bugs.python.org/issue14949. I might take care of that later.

Thanks again,
Alexis

From erik.m.bray at gmail.com  Tue May 29 16:08:03 2012
From: erik.m.bray at gmail.com (Erik Bray)
Date: Tue, 29 May 2012 10:08:03 -0400
Subject: [Distutils] Distutils2: Does uploading to pypi work yet?
In-Reply-To: <CAJRoPYZfeymyMpZ2_-sUbfx5nCnTTqqtFEoqiHNWkN21BMLo-g@mail.gmail.com>
References: <CAJRoPYZfeymyMpZ2_-sUbfx5nCnTTqqtFEoqiHNWkN21BMLo-g@mail.gmail.com>
Message-ID: <CAOTD34Z2XrB4w6u2zs8DHZCFBSCCB2ukLBF_wCM8BXcPKWN34Q@mail.gmail.com>

On Sun, May 27, 2012 at 11:19 AM, Todd DeLuca <todddeluca at gmail.com> wrote:
> I recently failed to upload a project to pypi using distutils2 and failed to
> install the project using pip. ?Are distutils2 and pip not yet supporting
> 'setup.cfg' only projects yet?
>
> The upload failed to upload the tarball to pypi because of what looks like a
> problem encoding a multipart form message with
> distutils2.util.encode_multipart(). I tried to fix that problem (using a
> base64 encoding) but ran into 500 http return code from the pypi server.
> The uploading code seems pretty 'alpha', so I was wondering if anyone is
> successfully using 'pysetup' to upload projects to pypi.
>
> After failing to upload the distribtion, I uploaded it to github and then
> registered my project with a github download url. ?Then I tried installing
> my project using pip and that failed too, since I did not have a setup.py,
> only a setup.cfg, in the project.
>
> I'm using python 2.7.3, pip 1.1, and distutils2 from
> hg.python.org/distutils2 (pulled and updated) on Mac OS X 10.6.8.

I can't speak for PyPI or pip, but not a lot of stuff works with
setup.cfg-only distutils2/packaging projects.  Though I'm fairly
certain they shouldn't be expected to work yet.

Shameless plug, but have you tried d2to1
(http://pypi.python.org/pypi/d2to1)?  It allows you to use a setup.cfg
with existing tools like pip by way of a simple stub setup.py.  It
might not suit all your needs, but it also might :)

Erik

From erik.m.bray at gmail.com  Tue May 29 16:20:31 2012
From: erik.m.bray at gmail.com (Erik Bray)
Date: Tue, 29 May 2012 10:20:31 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CALeMXf73CjRkxNG20p8nyQAV78aTbU0MKZ2r5mPcXFsFQtvGCA@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
	<CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
	<CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>
	<CALeMXf73CjRkxNG20p8nyQAV78aTbU0MKZ2r5mPcXFsFQtvGCA@mail.gmail.com>
Message-ID: <CAOTD34YDuPJKiaEpPfZUuHc8KeM8A8L6s0xbWofJUEKE0B9UsA@mail.gmail.com>

On Sun, May 27, 2012 at 12:58 PM, PJ Eby <pje at telecommunity.com> wrote:
> Is setup.cfg already in dist-info?? I guess if it isn't, you could just add
> it, using the same mechanism above.? Hm....? (goes to look at packaging
> docs)...? Ouch.? I'm seeing a bigger problem, which is that without either
> the ability to do "setup_requires" or to ship an sdist with a hook-altered
> setup.cfg, it doesn't look like you can actually implement all of
> setuptools' build functionality with just packaging.? (e.g. Setuptools can
> ship an sdist whose contents and version were determined using revision
> control info, but which does not then require the revision control tool when
> installing from the sdist, as the sdist contains a pre-built manifest, and a
> pre-built setup.cfg with hardcoded version numbers copied from the original
> revision control info.)

I've already got sort of a version of that for some of the packages I
maintain here:
https://svn.stsci.edu/trac/ssb/stsci_python/browser/stsci.distutils/trunk/stsci/distutils/hooks.py#L91

It's a basic setup_hook that tacks the SVN revision on to version
string in the metadata (and only if the version contains ".dev").  The
SVN info itself comes from a generated module called 'version.py' that
ships with the sdist and contains hard-coded version info and SVN
revisions.  The main reason it's a Python module is that it also
contains an __version__ that can be imported by the main module of the
package.

This particular solution works for me.  But the point is that it can
be done pretty easily.  However, the lack of a setup_requires-like
feature still makes things pretty impossible short of shipping a copy
of all the required setup hooks with the projects that use them.
Certainly doable, but far from ideal.

> I really hope I'm not going to have to write setuptools2 to work around
> these limitations.? ;-)?? (Preferably, if I do write a setuptools2, I hope
> it can all be done using proper setup hooks on top of packaging/distutils2,
> without monkeypatching anything.)
>

Please, please no monkeypatching :)

From erik.m.bray at gmail.com  Tue May 29 16:25:59 2012
From: erik.m.bray at gmail.com (Erik Bray)
Date: Tue, 29 May 2012 10:25:59 -0400
Subject: [Distutils] one project into several sub projects???
In-Reply-To: <CAAq8ydvFNGtWp9pnOSM=K8AbwdSV6Ofqajbpt3XmLmW8f3JcUQ@mail.gmail.com>
References: <CAAq8ydvFNGtWp9pnOSM=K8AbwdSV6Ofqajbpt3XmLmW8f3JcUQ@mail.gmail.com>
Message-ID: <CAOTD34ajs2YrHkE6eV81QPR8tPKxyDvdhfm_yP4tXKZEWmE1mQ@mail.gmail.com>

On Tue, May 29, 2012 at 12:04 AM, Rob Healey <robhealey1 at gmail.com> wrote:
> Greetings:
>
> I would like to know what would be the best way to handle this situation???
>
> I have a project that needs to be split into several smaller pieces/
> projects:
> 1) core
> 2) gui
> 3) cli
> 4) web
>
> Could you give me the best case scenario to split up this one project?? It
> would be best if I used DU2 or Packaging...? I need something that will be
> supported for as while to come...
>
> Our project will be moving into Python3 compatibility...

Rob,

That's a big question with no simple answer, and might be better
addressed to comp.lang.python or the like.  How you do this isn't tied
to the packaging framework you use (thought it might be best to keep
the packaging aspect as simple as possible).

Erik

From pje at telecommunity.com  Tue May 29 17:19:39 2012
From: pje at telecommunity.com (PJ Eby)
Date: Tue, 29 May 2012 11:19:39 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CAOTD34YDuPJKiaEpPfZUuHc8KeM8A8L6s0xbWofJUEKE0B9UsA@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4F920039.9050402@netwok.org>
	<CAAq8ydvOscAYhhQdwmqeu8qP2fV2Ptpa5RK+dtPaCqQ5gJWK1Q@mail.gmail.com>
	<4F924AEC.9030501@netwok.org> <4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
	<CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
	<CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>
	<CALeMXf73CjRkxNG20p8nyQAV78aTbU0MKZ2r5mPcXFsFQtvGCA@mail.gmail.com>
	<CAOTD34YDuPJKiaEpPfZUuHc8KeM8A8L6s0xbWofJUEKE0B9UsA@mail.gmail.com>
Message-ID: <CALeMXf78D94Tgmk47wZwkms0r20N3vPuB9wnfPjPF5eqjG7n=A@mail.gmail.com>

On Tue, May 29, 2012 at 10:20 AM, Erik Bray <erik.m.bray at gmail.com> wrote:

> This particular solution works for me.  But the point is that it can
> be done pretty easily.  However, the lack of a setup_requires-like
> feature still makes things pretty impossible short of shipping a copy
> of all the required setup hooks with the projects that use them.
> Certainly doable, but far from ideal.
>

Right, and I don't think distutils2 can really add setup_requires without
blessing a package manager.  That means the alternative is shipping an
altered setup.cfg with sdist builds, or using tools that generate setup.cfg
in the first place, such that setup.cfg isn't the project's canonical form.

Probably the simplest way to do it would be to just ship setup.cfg in the
sdist -- as modified by the setup hooks, since this keeps the developer
from having to use a different tool to generate the setup.cfg; it can all
be done by setup hooks.

In that case, the setup hooks themselves would need to be idempotent, so
they don't mess things up if they run a second time in an sdist-ed version
of the project.

Another alternative would be to use a package manager bootstrap script in
the project directory (ala ez_setup.py), which could then read and process
a setup_requires from setup.cfg.  But that's a much heavier-weight process;
it would be much preferable if people could make all their setup_requires
stuff run off an original copy only, and not be needed in an sdist copy.
So for example, if you need Pyrex for generating C code, it should run
pre-sdist, not post-sdist.

(OTOH, it's possible that there are some distributions you need for
building the package, for platform-specific build steps.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120529/03838fcd/attachment-0001.html>

From carl at oddbird.net  Tue May 29 19:24:47 2012
From: carl at oddbird.net (Carl Meyer)
Date: Tue, 29 May 2012 10:24:47 -0700
Subject: [Distutils] command hooks...
In-Reply-To: <CALeMXf78D94Tgmk47wZwkms0r20N3vPuB9wnfPjPF5eqjG7n=A@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
	<CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
	<CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>
	<CALeMXf73CjRkxNG20p8nyQAV78aTbU0MKZ2r5mPcXFsFQtvGCA@mail.gmail.com>
	<CAOTD34YDuPJKiaEpPfZUuHc8KeM8A8L6s0xbWofJUEKE0B9UsA@mail.gmail.com>
	<CALeMXf78D94Tgmk47wZwkms0r20N3vPuB9wnfPjPF5eqjG7n=A@mail.gmail.com>
Message-ID: <4FC5065F.6040000@oddbird.net>



On 05/29/2012 08:19 AM, PJ Eby wrote:
> On Tue, May 29, 2012 at 10:20 AM, Erik Bray <erik.m.bray at gmail.com
> <mailto:erik.m.bray at gmail.com>> wrote:
> 
>     This particular solution works for me.  But the point is that it can
>     be done pretty easily.  However, the lack of a setup_requires-like
>     feature still makes things pretty impossible short of shipping a copy
>     of all the required setup hooks with the projects that use them.
>     Certainly doable, but far from ideal.
> 
> 
> Right, and I don't think distutils2 can really add setup_requires
> without blessing a package manager.

I'm confused by this statement. distutils2 _includes_ a package manager
(pysetup); it has no need to bless an external one. What am I missing?

Carl

-------------- 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/20120529/263e76a9/attachment.pgp>

From pje at telecommunity.com  Tue May 29 23:01:24 2012
From: pje at telecommunity.com (PJ Eby)
Date: Tue, 29 May 2012 17:01:24 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FC5065F.6040000@oddbird.net>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4FA011F7.3010701@plope.com>
	<CACac1F8TZPoKNAemsmz90HjSe5NUU8zytQNX9jQzP9MzMY48cg@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
	<CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
	<CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>
	<CALeMXf73CjRkxNG20p8nyQAV78aTbU0MKZ2r5mPcXFsFQtvGCA@mail.gmail.com>
	<CAOTD34YDuPJKiaEpPfZUuHc8KeM8A8L6s0xbWofJUEKE0B9UsA@mail.gmail.com>
	<CALeMXf78D94Tgmk47wZwkms0r20N3vPuB9wnfPjPF5eqjG7n=A@mail.gmail.com>
	<4FC5065F.6040000@oddbird.net>
Message-ID: <CALeMXf7T77ChWoFXCDyjTEnMt29aabEY62-YUZvEDohbjBT3Yw@mail.gmail.com>

On Tue, May 29, 2012 at 1:24 PM, Carl Meyer <carl at oddbird.net> wrote:

>
>
> On 05/29/2012 08:19 AM, PJ Eby wrote:
> > On Tue, May 29, 2012 at 10:20 AM, Erik Bray <erik.m.bray at gmail.com
> > <mailto:erik.m.bray at gmail.com>> wrote:
> >
> >     This particular solution works for me.  But the point is that it can
> >     be done pretty easily.  However, the lack of a setup_requires-like
> >     feature still makes things pretty impossible short of shipping a copy
> >     of all the required setup hooks with the projects that use them.
> >     Certainly doable, but far from ideal.
> >
> >
> > Right, and I don't think distutils2 can really add setup_requires
> > without blessing a package manager.
>
> I'm confused by this statement. distutils2 _includes_ a package manager
> (pysetup); it has no need to bless an external one. What am I missing?
>

I might be confused; I haven't been following the goings-on of late with
distutils2.  At one point, I thought the plan was not to bless or include
dependency-managing installers with the stdlib, or something like that.
i.e., I thought the plan wasn't to support or bless full-service tools like
buildout, easy_install, or pip, or anything comparable to them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120529/95264838/attachment.html>

From carl at oddbird.net  Tue May 29 23:17:16 2012
From: carl at oddbird.net (Carl Meyer)
Date: Tue, 29 May 2012 14:17:16 -0700
Subject: [Distutils] command hooks...
In-Reply-To: <CALeMXf7T77ChWoFXCDyjTEnMt29aabEY62-YUZvEDohbjBT3Yw@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
	<CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
	<CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>
	<CALeMXf73CjRkxNG20p8nyQAV78aTbU0MKZ2r5mPcXFsFQtvGCA@mail.gmail.com>
	<CAOTD34YDuPJKiaEpPfZUuHc8KeM8A8L6s0xbWofJUEKE0B9UsA@mail.gmail.com>
	<CALeMXf78D94Tgmk47wZwkms0r20N3vPuB9wnfPjPF5eqjG7n=A@mail.gmail.com>
	<4FC5065F.6040000@oddbird.net>
	<CALeMXf7T77ChWoFXCDyjTEnMt29aabEY62-YUZvEDohbjBT3Yw@mail.gmail.com>
Message-ID: <4FC53CDC.6010808@oddbird.net>


On 05/29/2012 02:01 PM, PJ Eby wrote:
> On Tue, May 29, 2012 at 1:24 PM, Carl Meyer <carl at oddbird.net> wrote:
>     On 05/29/2012 08:19 AM, PJ Eby wrote:
>     > Right, and I don't think distutils2 can really add setup_requires
>     > without blessing a package manager.
> 
>     I'm confused by this statement. distutils2 _includes_ a package manager
>     (pysetup); it has no need to bless an external one. What am I missing?
> 
> I might be confused; I haven't been following the goings-on of late with
> distutils2.  At one point, I thought the plan was not to bless or
> include dependency-managing installers with the stdlib, or something
> like that.  i.e., I thought the plan wasn't to support or bless
> full-service tools like buildout, easy_install, or pip, or anything
> comparable to them.

Right, yeah, the plans in this area were fluid for awhile, but the
eventual conclusion was that the stdlib should have a command-line
utility capable of installing packages with dependencies. That exists in
default branch now; it's called pysetup. It doesn't have nearly all the
features of easy_install, buildout, or pip, but it can install packages
from an index with deps.

Carl

-------------- 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/20120529/e6b505b0/attachment.pgp>

From pje at telecommunity.com  Wed May 30 01:41:30 2012
From: pje at telecommunity.com (PJ Eby)
Date: Tue, 29 May 2012 19:41:30 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <4FC53CDC.6010808@oddbird.net>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
	<CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
	<CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>
	<CALeMXf73CjRkxNG20p8nyQAV78aTbU0MKZ2r5mPcXFsFQtvGCA@mail.gmail.com>
	<CAOTD34YDuPJKiaEpPfZUuHc8KeM8A8L6s0xbWofJUEKE0B9UsA@mail.gmail.com>
	<CALeMXf78D94Tgmk47wZwkms0r20N3vPuB9wnfPjPF5eqjG7n=A@mail.gmail.com>
	<4FC5065F.6040000@oddbird.net>
	<CALeMXf7T77ChWoFXCDyjTEnMt29aabEY62-YUZvEDohbjBT3Yw@mail.gmail.com>
	<4FC53CDC.6010808@oddbird.net>
Message-ID: <CALeMXf4HhM_JBjYDzig-9UF1-gv5baQt4jWb-DYkryo=DrrJfg@mail.gmail.com>

On Tue, May 29, 2012 at 5:17 PM, Carl Meyer <carl at oddbird.net> wrote:

>
> On 05/29/2012 02:01 PM, PJ Eby wrote:
> > On Tue, May 29, 2012 at 1:24 PM, Carl Meyer <carl at oddbird.net> wrote:
> >     On 05/29/2012 08:19 AM, PJ Eby wrote:
> >     > Right, and I don't think distutils2 can really add setup_requires
> >     > without blessing a package manager.
> >
> >     I'm confused by this statement. distutils2 _includes_ a package
> manager
> >     (pysetup); it has no need to bless an external one. What am I
> missing?
> >
> > I might be confused; I haven't been following the goings-on of late with
> > distutils2.  At one point, I thought the plan was not to bless or
> > include dependency-managing installers with the stdlib, or something
> > like that.  i.e., I thought the plan wasn't to support or bless
> > full-service tools like buildout, easy_install, or pip, or anything
> > comparable to them.
>
> Right, yeah, the plans in this area were fluid for awhile, but the
> eventual conclusion was that the stdlib should have a command-line
> utility capable of installing packages with dependencies. That exists in
> default branch now; it's called pysetup. It doesn't have nearly all the
> features of easy_install, buildout, or pip, but it can install packages
> from an index with deps.
>
>
In any case, it still doesn't change the part where it's a good idea to
ship a static setup.cfg, with hooks only needing to run on the
sdist-building machine, unless they are actually part of the build
process.  There are use cases for calculated data to be in the initial
setup.cfg, where the calculation machinery doesn't need to be on the target
(like generating the file list or version from revision control info).  So,
a setup_requires (or maybe better named "build_requires") would still be
helpful, but probably shouldn't be used for setup.cfg stability.

One use case I ran across rather late in the game with setuptools was the
part where sdist distributions need to be capable of rebuilding an sdist,
for at least the bdist_rpm case, if not others.  That had me tearing my
hair, since I was dependent on what I could do on top of existing
distutils.  But for distutils2, shipping an updated setup.cfg (possibly
*minus* certain setup_hooks) would solve the problem nicely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120529/604f64e0/attachment.html>

From erik.m.bray at gmail.com  Wed May 30 17:54:25 2012
From: erik.m.bray at gmail.com (Erik Bray)
Date: Wed, 30 May 2012 11:54:25 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CALeMXf4HhM_JBjYDzig-9UF1-gv5baQt4jWb-DYkryo=DrrJfg@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
	<CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
	<CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>
	<CALeMXf73CjRkxNG20p8nyQAV78aTbU0MKZ2r5mPcXFsFQtvGCA@mail.gmail.com>
	<CAOTD34YDuPJKiaEpPfZUuHc8KeM8A8L6s0xbWofJUEKE0B9UsA@mail.gmail.com>
	<CALeMXf78D94Tgmk47wZwkms0r20N3vPuB9wnfPjPF5eqjG7n=A@mail.gmail.com>
	<4FC5065F.6040000@oddbird.net>
	<CALeMXf7T77ChWoFXCDyjTEnMt29aabEY62-YUZvEDohbjBT3Yw@mail.gmail.com>
	<4FC53CDC.6010808@oddbird.net>
	<CALeMXf4HhM_JBjYDzig-9UF1-gv5baQt4jWb-DYkryo=DrrJfg@mail.gmail.com>
Message-ID: <CAOTD34YpjpH7D=QSuOUm+ek26nGsYde2bH88FL9DX7ecniYN6w@mail.gmail.com>

On Tue, May 29, 2012 at 7:41 PM, PJ Eby <pje at telecommunity.com> wrote:
>> > I might be confused; I haven't been following the goings-on of late with
>> > distutils2. ?At one point, I thought the plan was not to bless or
>> > include dependency-managing installers with the stdlib, or something
>> > like that. ?i.e., I thought the plan wasn't to support or bless
>> > full-service tools like buildout, easy_install, or pip, or anything
>> > comparable to them.
>>
>> Right, yeah, the plans in this area were fluid for awhile, but the
>> eventual conclusion was that the stdlib should have a command-line
>> utility capable of installing packages with dependencies. That exists in
>> default branch now; it's called pysetup. It doesn't have nearly all the
>> features of easy_install, buildout, or pip, but it can install packages
>> from an index with deps.
>>
>
> In any case, it still doesn't change the part where it's a good idea to ship
> a static setup.cfg, with hooks only needing to run on the sdist-building
> machine, unless they are actually part of the build process.? There are use
> cases for calculated data to be in the initial setup.cfg, where the
> calculation machinery doesn't need to be on the target (like generating the
> file list or version from revision control info).? So, a setup_requires (or
> maybe better named "build_requires") would still be helpful, but probably
> shouldn't be used for setup.cfg stability.

That's not a bad idea for certain kinds of metadata--version/vcs info
for example.  I like the idea of including a generated "static"
setup.cfg in a source dist as a solution to that kind of problem.  But
that doesn't eliminate the need for setup_hooks (or even more
complicated objects like custom commands) in an sdist.

For example, the majority of projects I work on require Numpy to build
one or two extension modules.  They require hooks to check that the
numpy package is importable, and then to use numpy's API to get the
paths to the numpy headers and and them to the include_dirs for each
extension module that requires them.  That's not the only one
though--one could have a whole suite of setup_hooks common to a bunch
of projects.  Custom Compiler classes are a possibility now too.

One could ship a copy of those dependencies with each project, or have
some kind of bootstrap script.  But to be able to automatically
download and add build dependencies to the path (a la setup_requires)
would be much nicer.  And packaging will have pysetup, so it should be
doable.  (Having the same capability for test dependencies and doc
dependencies would be nice too, but not nearly as important).

Erik

From dholth at gmail.com  Wed May 30 18:05:43 2012
From: dholth at gmail.com (Daniel Holth)
Date: Wed, 30 May 2012 12:05:43 -0400
Subject: [Distutils] Requires-Dist: unittest2; 'test' in extras
Message-ID: <CAG8k2+4SJP9CSLGyWweOZtASkum=gVTZ4FyNvNij7-zsEz=5MQ@mail.gmail.com>

Proposal:

Requires-Dist: unittest2; 'test' in extras

...

I noticed very few packages (I counted 644 out of 16k) actually include
Requires: in the sdist PKG-INFO, 5 with Requires-Dist. (requires.txt is
much more common.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120530/4e4d2860/attachment.html>

From pje at telecommunity.com  Wed May 30 18:19:53 2012
From: pje at telecommunity.com (PJ Eby)
Date: Wed, 30 May 2012 12:19:53 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CAOTD34YpjpH7D=QSuOUm+ek26nGsYde2bH88FL9DX7ecniYN6w@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
	<CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
	<CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>
	<CALeMXf73CjRkxNG20p8nyQAV78aTbU0MKZ2r5mPcXFsFQtvGCA@mail.gmail.com>
	<CAOTD34YDuPJKiaEpPfZUuHc8KeM8A8L6s0xbWofJUEKE0B9UsA@mail.gmail.com>
	<CALeMXf78D94Tgmk47wZwkms0r20N3vPuB9wnfPjPF5eqjG7n=A@mail.gmail.com>
	<4FC5065F.6040000@oddbird.net>
	<CALeMXf7T77ChWoFXCDyjTEnMt29aabEY62-YUZvEDohbjBT3Yw@mail.gmail.com>
	<4FC53CDC.6010808@oddbird.net>
	<CALeMXf4HhM_JBjYDzig-9UF1-gv5baQt4jWb-DYkryo=DrrJfg@mail.gmail.com>
	<CAOTD34YpjpH7D=QSuOUm+ek26nGsYde2bH88FL9DX7ecniYN6w@mail.gmail.com>
Message-ID: <CALeMXf5FRub6-giOrJrX5tUfZaX1Wpnm_h3fwRd_xPt6WY_O8Q@mail.gmail.com>

On Wed, May 30, 2012 at 11:54 AM, Erik Bray <erik.m.bray at gmail.com> wrote:

> On Tue, May 29, 2012 at 7:41 PM, PJ Eby <pje at telecommunity.com> wrote:
> >> > I might be confused; I haven't been following the goings-on of late
> with
> >> > distutils2.  At one point, I thought the plan was not to bless or
> >> > include dependency-managing installers with the stdlib, or something
> >> > like that.  i.e., I thought the plan wasn't to support or bless
> >> > full-service tools like buildout, easy_install, or pip, or anything
> >> > comparable to them.
> >>
> >> Right, yeah, the plans in this area were fluid for awhile, but the
> >> eventual conclusion was that the stdlib should have a command-line
> >> utility capable of installing packages with dependencies. That exists in
> >> default branch now; it's called pysetup. It doesn't have nearly all the
> >> features of easy_install, buildout, or pip, but it can install packages
> >> from an index with deps.
> >>
> >
> > In any case, it still doesn't change the part where it's a good idea to
> ship
> > a static setup.cfg, with hooks only needing to run on the sdist-building
> > machine, unless they are actually part of the build process.  There are
> use
> > cases for calculated data to be in the initial setup.cfg, where the
> > calculation machinery doesn't need to be on the target (like generating
> the
> > file list or version from revision control info).  So, a setup_requires
> (or
> > maybe better named "build_requires") would still be helpful, but probably
> > shouldn't be used for setup.cfg stability.
>
> That's not a bad idea for certain kinds of metadata--version/vcs info
> for example.  I like the idea of including a generated "static"
> setup.cfg in a source dist as a solution to that kind of problem.  But
> that doesn't eliminate the need for setup_hooks (or even more
> complicated objects like custom commands) in an sdist.
>
> For example, the majority of projects I work on require Numpy to build
> one or two extension modules.  They require hooks to check that the
> numpy package is importable, and then to use numpy's API to get the
> paths to the numpy headers and and them to the include_dirs for each
> extension module that requires them.  That's not the only one
> though--one could have a whole suite of setup_hooks common to a bunch
> of projects.  Custom Compiler classes are a possibility now too.
>
> One could ship a copy of those dependencies with each project, or have
> some kind of bootstrap script.  But to be able to automatically
> download and add build dependencies to the path (a la setup_requires)
> would be much nicer.  And packaging will have pysetup, so it should be
> doable.  (Having the same capability for test dependencies and doc
> dependencies would be nice too, but not nearly as important).
>

Certainly.  I was just saying that the generated-metadata cases need
handling, too, and that people should also be informed that they don't need
(and shouldn't use) setup_requires for simple metadata generation, and that
it might be a good idea to call the feature "build_requires", and perhaps
distinguish between "setup hooks" (for developers to have nice things) and
"build hooks" (for stuff that absolutely has to run on the install machine).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120530/15e81e3c/attachment.html>

From erik.m.bray at gmail.com  Wed May 30 18:34:00 2012
From: erik.m.bray at gmail.com (Erik Bray)
Date: Wed, 30 May 2012 12:34:00 -0400
Subject: [Distutils] command hooks...
In-Reply-To: <CALeMXf5FRub6-giOrJrX5tUfZaX1Wpnm_h3fwRd_xPt6WY_O8Q@mail.gmail.com>
References: <CAAq8ydudw70zpy4QXcW2r5PkUfXauv4rfinyF7YE_jXJ1GkrkA@mail.gmail.com>
	<4FB2BEE8.9030908@netwok.org> <4FB309B3.5060406@plope.com>
	<4FB34F4C.9080901@ziade.org> <4FB3D519.1000009@plope.com>
	<4FBAACA8.9010108@ziade.org> <4FBDB234.5080805@plope.com>
	<CAOTD34bMcDA6JZNqzXW2bvZC8eN4wXjK3oemU9UOPXiss+Gc8A@mail.gmail.com>
	<CAG8k2+5Y=wOfYcO3qW5R=FjgTvHh42=nzfVDZYp+dFYESeop1A@mail.gmail.com>
	<CALeMXf6mG63HOJmLAi=gxVBFYo6=i0T087eaAOPucVECn3r3VA@mail.gmail.com>
	<CAOTD34bDH7o2An3mPvc5VhPPCu+wjPCDv6JB2DRW1UygJ+Tnkg@mail.gmail.com>
	<CAG8k2+4C0hORixDB6a0dP3Kny2mNHtdNd5LdSniL-LLt5U5S2w@mail.gmail.com>
	<CAOTD34ZeKL8UtuiOw37aHM0O2dQXcEvW75JOXqZqciQY24=0rg@mail.gmail.com>
	<CALeMXf73CjRkxNG20p8nyQAV78aTbU0MKZ2r5mPcXFsFQtvGCA@mail.gmail.com>
	<CAOTD34YDuPJKiaEpPfZUuHc8KeM8A8L6s0xbWofJUEKE0B9UsA@mail.gmail.com>
	<CALeMXf78D94Tgmk47wZwkms0r20N3vPuB9wnfPjPF5eqjG7n=A@mail.gmail.com>
	<4FC5065F.6040000@oddbird.net>
	<CALeMXf7T77ChWoFXCDyjTEnMt29aabEY62-YUZvEDohbjBT3Yw@mail.gmail.com>
	<4FC53CDC.6010808@oddbird.net>
	<CALeMXf4HhM_JBjYDzig-9UF1-gv5baQt4jWb-DYkryo=DrrJfg@mail.gmail.com>
	<CAOTD34YpjpH7D=QSuOUm+ek26nGsYde2bH88FL9DX7ecniYN6w@mail.gmail.com>
	<CALeMXf5FRub6-giOrJrX5tUfZaX1Wpnm_h3fwRd_xPt6WY_O8Q@mail.gmail.com>
Message-ID: <CAOTD34ZSJ3N7bQ1_VnSTffg8xBQkxo1EH+PgdYdAcGSDpMXo1Q@mail.gmail.com>

On Wed, May 30, 2012 at 12:19 PM, PJ Eby <pje at telecommunity.com> wrote:
>
>
> On Wed, May 30, 2012 at 11:54 AM, Erik Bray <erik.m.bray at gmail.com> wrote:
>>
>> On Tue, May 29, 2012 at 7:41 PM, PJ Eby <pje at telecommunity.com> wrote:
>> >> > I might be confused; I haven't been following the goings-on of late
>> >> > with
>> >> > distutils2. ?At one point, I thought the plan was not to bless or
>> >> > include dependency-managing installers with the stdlib, or something
>> >> > like that. ?i.e., I thought the plan wasn't to support or bless
>> >> > full-service tools like buildout, easy_install, or pip, or anything
>> >> > comparable to them.
>> >>
>> >> Right, yeah, the plans in this area were fluid for awhile, but the
>> >> eventual conclusion was that the stdlib should have a command-line
>> >> utility capable of installing packages with dependencies. That exists
>> >> in
>> >> default branch now; it's called pysetup. It doesn't have nearly all the
>> >> features of easy_install, buildout, or pip, but it can install packages
>> >> from an index with deps.
>> >>
>> >
>> > In any case, it still doesn't change the part where it's a good idea to
>> > ship
>> > a static setup.cfg, with hooks only needing to run on the sdist-building
>> > machine, unless they are actually part of the build process.? There are
>> > use
>> > cases for calculated data to be in the initial setup.cfg, where the
>> > calculation machinery doesn't need to be on the target (like generating
>> > the
>> > file list or version from revision control info).? So, a setup_requires
>> > (or
>> > maybe better named "build_requires") would still be helpful, but
>> > probably
>> > shouldn't be used for setup.cfg stability.
>>
>> That's not a bad idea for certain kinds of metadata--version/vcs info
>> for example. ?I like the idea of including a generated "static"
>> setup.cfg in a source dist as a solution to that kind of problem. ?But
>> that doesn't eliminate the need for setup_hooks (or even more
>> complicated objects like custom commands) in an sdist.
>>
>> For example, the majority of projects I work on require Numpy to build
>> one or two extension modules. ?They require hooks to check that the
>> numpy package is importable, and then to use numpy's API to get the
>> paths to the numpy headers and and them to the include_dirs for each
>> extension module that requires them. ?That's not the only one
>> though--one could have a whole suite of setup_hooks common to a bunch
>> of projects. ?Custom Compiler classes are a possibility now too.
>>
>> One could ship a copy of those dependencies with each project, or have
>> some kind of bootstrap script. ?But to be able to automatically
>> download and add build dependencies to the path (a la setup_requires)
>> would be much nicer. ?And packaging will have pysetup, so it should be
>> doable. ?(Having the same capability for test dependencies and doc
>> dependencies would be nice too, but not nearly as important).
>
>
> Certainly.? I was just saying that the generated-metadata cases need
> handling, too, and that people should also be informed that they don't need
> (and shouldn't use) setup_requires for simple metadata generation, and that
> it might be a good idea to call the feature "build_requires", and perhaps
> distinguish between "setup hooks" (for developers to have nice things) and
> "build hooks" (for stuff that absolutely has to run on the install machine).

I think we're on the same page then :)  packaging/d2 also supports
pre/post-command hooks which might, in most cases, be more appropriate
for the "build hooks that absolutely have to run" case.  In fact, I
had completely forgotten this, but my aforementioned Numpy extension
module hook is a pre-build_ext hook.  That makes it absolutely clear
that this is something we have to do before we can build an extension
module, and that it doesn't have any purpose outside that context and
shouldn't be executed ever time I run `pysetup something`.

Erik

From dholth at gmail.com  Wed May 30 21:09:57 2012
From: dholth at gmail.com (Daniel Holth)
Date: Wed, 30 May 2012 15:09:57 -0400
Subject: [Distutils] Requires-Dist: unittest2; 'test' in extras
In-Reply-To: <CAG8k2+4SJP9CSLGyWweOZtASkum=gVTZ4FyNvNij7-zsEz=5MQ@mail.gmail.com>
References: <CAG8k2+4SJP9CSLGyWweOZtASkum=gVTZ4FyNvNij7-zsEz=5MQ@mail.gmail.com>
Message-ID: <CAG8k2+6c4i_Qs20VfVT1Ae4OoC8xeaHT-jYPtDPdmBO_wTC5NQ@mail.gmail.com>

It looks like you can only install one extra at a time, so the more pleasing

Requires-Dist: somedist; extra == 'test'

would be correct.

On Wed, May 30, 2012 at 12:05 PM, Daniel Holth <dholth at gmail.com> wrote:

> Proposal:
>
> Requires-Dist: unittest2; 'test' in extras
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120530/523ec1e1/attachment.html>

From junderhill at lanl.gov  Wed May 30 22:16:00 2012
From: junderhill at lanl.gov (Underhill, Jennifer M)
Date: Wed, 30 May 2012 20:16:00 +0000
Subject: [Distutils] Problem Installing Pysam Wrapping for SAMtools
Message-ID: <B9BE8563780A604C8AD200B2BA370135E41A28@ECS-EXG-P-MB05.win.lanl.gov>

To whom it may concern:

I am very new to programming so I apologize if this question is overly simple.

When I attempt to install the wrapping system for SAMtools using pysam, I receive this error message:

[Errno 13] Permission denied: '/Library/Python/2.6/site-packages/test-easy-install-45999.write-test'

I do not have administrative access to my computer, and I would like to know if it would be possible to specify a directory for the package to be installed in.

I am working on a Mac OSX and using the Terminal shell. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120530/6ef3026c/attachment.html>

From dholth at gmail.com  Wed May 30 22:50:04 2012
From: dholth at gmail.com (Daniel Holth)
Date: Wed, 30 May 2012 16:50:04 -0400
Subject: [Distutils] Problem Installing Pysam Wrapping for SAMtools
In-Reply-To: <B9BE8563780A604C8AD200B2BA370135E41A28@ECS-EXG-P-MB05.win.lanl.gov>
References: <B9BE8563780A604C8AD200B2BA370135E41A28@ECS-EXG-P-MB05.win.lanl.gov>
Message-ID: <CAG8k2+41PsQ8RdHWW=s+H=MB9eP=qFLhZewriK=3XLiks4xdpg@mail.gmail.com>

Try

python setup.py --user

It should install somewhere in ~/.local/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120530/d4e415d2/attachment.html>

From pje at telecommunity.com  Wed May 30 23:35:28 2012
From: pje at telecommunity.com (PJ Eby)
Date: Wed, 30 May 2012 17:35:28 -0400
Subject: [Distutils] Requires-Dist: unittest2; 'test' in extras
In-Reply-To: <CAG8k2+6c4i_Qs20VfVT1Ae4OoC8xeaHT-jYPtDPdmBO_wTC5NQ@mail.gmail.com>
References: <CAG8k2+4SJP9CSLGyWweOZtASkum=gVTZ4FyNvNij7-zsEz=5MQ@mail.gmail.com>
	<CAG8k2+6c4i_Qs20VfVT1Ae4OoC8xeaHT-jYPtDPdmBO_wTC5NQ@mail.gmail.com>
Message-ID: <CALeMXf4bJvGCzJKip+ypS-v_U_=AU-5=PzRHmQ_cnh1gS252Sg@mail.gmail.com>

On Wed, May 30, 2012 at 3:09 PM, Daniel Holth <dholth at gmail.com> wrote:

> It looks like you can only install one extra at a time,


Actually, you can specify more than one, using commas.  e.g. "easy_install
foo[testing,c-extensions,celery-support,...]".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120530/056e088e/attachment.html>

From benoit at marmelune.net  Thu May 31 00:10:44 2012
From: benoit at marmelune.net (=?ISO-8859-1?Q?Beno=EEt_Bryon?=)
Date: Thu, 31 May 2012 00:10:44 +0200
Subject: [Distutils] conventions or best practice to choose package
	names?
In-Reply-To: <CAPDm-FgW_QjVWV30SdYTvnXZzCeDYg=vTpwVjVsBKraVjZeEiw@mail.gmail.com>
References: <4FB02B36.8040504@marmelune.net>
	<CAPDm-FgW_QjVWV30SdYTvnXZzCeDYg=vTpwVjVsBKraVjZeEiw@mail.gmail.com>
Message-ID: <4FC69AE4.10904@marmelune.net>

Hello,

Le 14/05/2012 13:12, Jim Fulton a ?crit :
> +1 for an official document (or addition to an existinhg document)
>     providing a rational for namespace packages and their naming.
>
I opened a ticket on CPython issue tracker:
http://bugs.python.org/issue14899

Then started to work in a fork:
https://bitbucket.org/benoitbryon/cpython/src/doc-package-names/Doc/packaging/packagenames.rst

.. but it looks like a PEP. So, I followed PEP 1
and posted the proposal to python-list at python.org...
where I've been told to post it to distutils-sig :)
So, I'm back here with a proposal...

The document below is the same as current version of
https://bitbucket.org/benoitbryon/cpython/src/doc-package-names/Doc/packaging/packagenames.rst.

Thanks to Martin Aspeli for his article.
Thanks to early reviewers: Alexis M?taireau, ?ric Br?hault,
Jean-Philippe Camguilhem and Mathieu Lepl?tre.

Benoit



###########################################
Names in packaging: conventions and recipes
###########################################

This document deals with:

* names of Python projects,
* names of distributions in projects,
* names of Python packages or modules being distributed,
* namespace packages.

It provides conventions and recipes for distribution authors.

Main use case is:

* as a developer, I want to create a project in order to distribute a package.
   So I have to choose names.  Which names are "good"?

* `The Zen of Python`_ says:

     In the face of ambiguity, refuse the temptation to guess.
     There should be one-- and preferably only one --obvious way to do it.

* So I need clear and official (i.e. obvious) guidelines or conventions that I
   can follow.

* Here are conventions, guidelines and recipes.

Guidelines for existing projects are also given.


***********
Terminology
***********

First of all, let's make sure there is no confusion...

Distribution name
   Distribution name is used by packaging utilities:

   * in :doc:`setup script</packaging/setupscript>`, it is the value passed as
     ``name`` to ``packaging.core.setup()``
   * it appears on `PyPI`_ if the package is registered on it
   * it can be used in `pip` requirements files
   * it can be used in `buildout` configuration files.

   Distribution term is introduced in :doc:`packaging docs</packaging/index>`.

Egg name
   It is the same concept as distribution name. Technically, the egg is not the
   distribution. But they use the same name: it is declared as
   ``packaging.core.setup()`` name argument.

   "Egg" term is the legacy counterpart to "distribution". It was used by
   distutils and setuptools. It becomes deprecated with the new packaging
   module.

   This document focuses on distributions, not eggs.

Package and module names
   Package and module names are used in Python code. It is the string used in
   :ref:`import statements<import>`.

   Remember that, from a file system perspective, packages are directories and
   modules are files.

   :ref:`Python packaging allows distributions to distribute several packages
   and/or modules<setupcfg-section-files>`.

Project name
   Usually the name of the repository or folder in which distribution authors put
   their code. It generally is the directory name of the "distribution root",
   as defined in :ref:`packaging-term`.

Namespace packages
   It is common practice to use namespaces in package names. `PEP 420`_ brings
   this concept to core Python. When PEP 420 will be accepted, Python officially
   supports namespace packages.

As an example, consider `django-debug-toolbar`_:

* ``django-debug-toolbar`` is the distribution name. `It is declared in
   setup.py file
   <https://github.com/django-debug-toolbar/django-debug-toolbar/blob/599d76e41c5728c0e342d55250690b2694bd2aad/setup.py#L4>`_.

* ``debug_toolbar`` is the package name. It is what would appear in Django's
   INSTALLED_APPS setting or be used as ``import debug_toolbar``.

Technically, all those names can be different.


*********
Rationale
*********

Relationship with other PEPs
============================

* `PEP 8`_ deals with code style guide, including names of Python packages and
   modules. It covers syntax of package/modules names.

* `PEP 345`_ deals with packaging metadata, and defines distribution name.

* `PEP 420`_ deals with namespace packages. It brings support of namespace
   packages to Python core. Before, namespaces packages were implemented by
   external libraries.

* `PEP 3108`_ deals with transition between Python 2.x and Python 3.x applied
   to standard library: some modules to be deleted, some to be renamed.

Other sources of inspiration
============================

* `Martin Aspeli's article about names`_. Some parts of this proposal are
   quotes from this article.

* `The Hitchhiker's Guide to Packaging`_, which has an empty placeholder
   for "naming specification".

* and, of course, `in development official packaging documentation`_.

Facts
=====

Before Python version 3.3, there is no official guidelines to name projects,
distributions or packages/modules.
Current PEPs (see `Relationship with other PEPs`_) are very open on this topic.

Distribution authors have to follow their own intuition.

Several standards emerged from communities. As examples:

* `Plone`_ community uses "plone.*" namespace for official Plone products, and
   "collective.*" for community products. This is a convention explicitely
   promoted by Plone community.
   `Martin Aspeli's article about names`_ is about conventions and usages in
   Plone community.

   .. note:: Is there an official document about these conventions? A PLIP?

* most `Django`_ applications from community use "django-\*" pattern as
   distribution name. This is a de facto standard.

* many `Pyramid`_ applications from community use "pyramid_*" pattern as
   distribution name.

Thus, as `PyPI`_ testifies, distribution names and package/module names are
really heterogeneous.

Impacts
=======

Here are points this document tries to resolve.

Ambiguity
---------

When distribution authors come to choose a name, they can't find an unique
official guideline.
In such a situation, "Now is better than never" wins over "Refuse temptation
to guess".
So distribution authors follow one of the conventions they discovered (usually
the one from their community), or follow their own intuition.

Confusion
---------

As explained in `terminology`_ above, project, distribution and package names
can be assigned distinct values. That is a big source of confusion, especially
for Python developers who are not used to packaging.

Time loss
---------

As a direct consequence of `ambiguity`_ and `confusion`_, new Python developers
spend too much time to understand Python projects/distributions/packages names:

* they can't find obvious (i.e. official) naming conventions (or at least
   guidelines) even if they search for it. They have to ask community to resolve
   the `ambiguity`_.

* it's hard to resolve the `confusion`_ between names. It's even harder because
   community itself is a bit confused. Their best chance is to find one of the
   `Other sources of inspiration`_ listed above or ask a well informed person.

* developers from some other languages suppose Python have official naming
   conventions for distributions and packages. So they search for it, and feel
   worried when they figure out that it doesn't exist.

Experienced Python users are less affected: they built their opinion in the
past and keep on following their habits.

Community partitionning
-----------------------

The global Python community is partitionned into opposed sub-communities:

* most Python developers are linked to at least one community (i.e. Zope,
   Plone, Pyramid, Django...).

* communities usually resolved naming conventions with official documents
   or with de facto usage.

* developers usually follow their community's standards.

* developers usually believe their community made the best choice. They usually
   adhere to community arguments.

* choices and reasons differ from one community to another.

* when Python communities meet, package names are a never-ending topic of
   discussion.

* people discuss about package names when they should work together on more
   valuable stories.

* they can't settle the issue, because:

   * arguments have historical reasons. In history, these reasons were enough.

   * accepting someone else's arguments means changing habits, and maybe
     re-packaging existing projects, i.e. efforts and time.

   * there is no guidelines from an higher authorithy (i.e. python.org). There
     is no comparison standard. Both choices are legitimate.

An additional note about developers who belong to several communities:

* they usually adhere to the naming conventions from one community,
* it's hard to adopt another convention when contributing in another community.

Proposal
========

As `The Zen of Python`_ says: "There should be one-- and preferably only one
--obvious way to do it."

So the proposal is:

* adopt strict conventions where Python community finds a consensus,
* provide guidelines or recipes for what cannot be covered by conventions.

What about existing projects?
=============================

It's impossible to **require** a change for every existing project, for obvious
reasons.

But it is possible to first **document** existing naming conventions, then
**promote** a change.

This document proposes two things:

* a status on current existing naming conventions, inside each project or
   community. So that custom naming conventions are at least self-documented.
   See `Organize community contributions`_ for details.

* a `Transition plan`_ for those who are ready to migrate.

.. _`packagenames-opportunity`:

Opportunity
===========

As of Python 3.3 being developed:

* many projects are not Python 3.x compatible. It includes "big" products or
   frameworks. It means that many projects will have to do a migration to
   support Python 3.x.

* packaging (aka distutils2) is on the starting blocks. When it is released,
   projects will be invited to migrate and use new packaging.

* `PEP 420`_ brings official support of namespace packages to Python.

It means that most active projects should be about to migrate in the next
year(s) to support Python 3.x, new packaging or new namespace packages.

Such an opportunity is unique and won't come again soon!
So let's introduce and promote naming conventions as soon as possible (i.e.
**now**).


***************
Transition plan
***************

New distributions
=================

In order of priority:

1. If the project belongs to a community (i.e. product/framework), **and** the
    community have official conventions, then follow community conventions.

    .. note::

       :ref:`Communities SHOULD organize contributions
       <packagenames-organizecommunities>`.

    As an example new community project related to Plone should be distributed
    as "collective.*", because it is an explicit standard of the Plone
    community.

2. New projects SHOULD follow `Conventions`_ described in this document.

Existing projects
=================

**There is no obligation for existing distributions to be renamed**. The choice
is left to distribution authors and mainteners for obvious reasons.

However, distribution authors are invited to `promote migrations`_.

In order to rename an existing distribution, follow `Renaming howto`_
guidelines below.

Promote migrations
==================

Every Python developer should migrate whenever possible, or promote the
migrations in their respective communities.

Apply this convention on your projects, then the community will see it is
safe.

In particular, "leaders" such as authors of popular projects are influential,
they have power and, thus, responsability over communities.

Apply this conventions on popular projects, then communities will adopt the
conventions too.

**Popular projects SHOULD promote migrations when they release a new (major)
version**, particularly :ref:`if this version introduces support for Python
3.x, new standard library's packaging or namespace packages
<packagenames-opportunity>`.

.. note::

    On the contrary, if popular projects refuse the conventions, communities
    may not adopt the conventions.

Improved handling of renamed distributions on PyPI
==================================================

If many projects follow `Renaming howto`_, many legacy distributions will have
the following characteristics:

* ``Development Status :: 7 - Inactive`` classifier.
* latest version is empty, except packaging stuff.
* lastest version "redirects" to another distribution. E.g. it has a single
   dependency on the renamed distribution.
* referenced as ``Obsoletes-Dist`` in a newer distribution.

So it will be possible to detect renamed distributions and improve readability
on PyPI. So that users can focus on active distributions. But this feature is
not required now. There is no urge. It won't be covered in this document.


***********
Conventions
***********

Rules that you SHOULD follow.

If in doubt, ask
================

If you feel unsure after reading the following conventions, ask `Python
community`_ on IRC or on a mailing list.

Use a single name
=================

Distribute only one package (or only one module) in a distribution, and use
package (or module) name as project name and distribution name.

* It avoids possible confusion between all those names.
* It makes the name consistent.
* It is explicit: when one sees distribution name, he guesses package name, and
   vice versa.
* It also limits implicit clashes between package/module names.
   By using a single name, when you register a name to PyPI, you also perform a
   basic package/module name availability verification.

   As an example, `pipeline`_, `python-pipeline`_ and `django-pipeline`_ all
   distribute a package or module called "pipeline". So installing two of them
   leads to errors.

Yes:

* Package name: "kheops.pyramid",
   i.e. ``import kheops.pyramid``

* distribution name: "kheops.pyramid",
   i.e. ``pip install kheops.pyramid``

* Project name: "kheops.pyramid",
   i.e. ``git clone git at github.com/pharaohs/kheops.pyramid.git``

No:

* Package name: "kheops"
* Distribution name: "kheops-pyramid"
* Project name: "KheopsPyramid"

.. note::

    For historical reasons, on `PyPI`_, you can find many distributions using
    different values for project, distribution and package/module name.

Multiple packages/modules should be rare
----------------------------------------

Technically, Python distributions can provide multiple packages and/or modules.
See :ref:`setup script reference<packaging-setup-script>` for details.

Some distributions actually does.
As an example, `setuptools`_ and `distribute`_ are both declaring
"pkg_resources", "easy_install" and "site" modules in addition to respective
"setuptools" and "distribute" packages.

Consider this use case as exceptional. In most cases, you don't need this
feature. So a distribution should provide only one package or module at a time.

Explicit distinct names should be rare
--------------------------------------

A notable exception to the "Use a single name" rule is when you explicitely
need distinct names.

As an example, the `Pillow`_ distribution is an alternative to the original
`PIL`_ distribution. They both provide a "PIL" package.

Consider this use case as exceptional. In most cases, you don't need this
feature. So a distributed package name should be equal to distribution name.

Follow PEP 8 for package names syntax
=====================================

`PEP 8`_ applies to Python package and module names.

If you `Use a single name`_, `PEP 8`_ also applies to project and distribution
names. The exceptions are namespace packages, where dots are required in the
name.

Pick meaningful names
=====================

Ask yourself "how would I describe in one sentence what this name is for?", and
then "could anyone have guessed that by looking at the name?".

When you are using namespaces, make sure each part is meaningful.

.. _`packagenames-ownership`:

Top level namespace relates to code ownership
=============================================

This helps avoid clashes between distribution names.

Ownership could be:

* an individual.
   Example: `gp.fileupload`_ is owned and maintained by Gael Pasgrimaud.

* an organization.
   Examples:

   * `zest.releaser`_ is owned and maintained by Zest Software.
   * `Django`_ is owned and maintained by the Django Software Fundation.

* a group or community.
   Example: `sphinx`_ is maintained by developers of the Sphinx project, not
   only by its author, Georg Brandl.

* a group or community related to another package.
   Example: `collective.recaptcha`_ is owned by its author: David Glick,
   Groundwire. But the "collective" namespace is owned by Plone community.

Respect ownership
-----------------

Understand the purpose of namespace before you use it.

**DO NOT** plug into a namespace you don't own, unless explicitely authorized.

`If in doubt, ask`_.

As an example, **DO NOT** use "django.contrib" namespace: it is managed by
Django's core contributors.

Exceptions CAN be defined by distribution authors. See `Organize community
contributions`_ below.

Private (including closed-source) distributions use a namespace
---------------------------------------------------------------

... because private distributions are owned by somebody. So apply the
:ref:`ownership rule<packagenames-ownership>`.

For internal/customer projects, use your company name as the namespace.

This rule applies to closed-source distributions.

As an example, if you are creating a "climbing" distribution for the "Python
Sport" company: use "pythonsport.climbing" name, even if it is closed source.

Individual projects use a namespace
-----------------------------------

... because they are owned by individuals. So apply the :ref:`ownership rule
<packagenames-ownership>`.

There is no shame in releasing a distribution as open source even if it has an
"internal" name.

If the project comes to a point where the author wants to change ownership
(i.e. the project no longer belongs to an individual), keep in mind :ref:`it is
easy to rename the project<packagenames-rename>`.

Independant community Python projects CAN avoid namespaces
----------------------------------------------------------

If your project is generic enough (i.e. it is not a contrib to another product
or framework), you CAN avoid namespaces. The base condition is generally that
your project is owned by a group (i.e. the development team) which is dedicated
to this project.

Only use a "shared" namespace if you really intend the code to be community
owned.

As an example, `sphinx`_ project belongs to the Sphinx development team.

In doubt, use an individual/organization namespace
--------------------------------------------------

If your project is not mature or hasn't been proven useful to a community,
best choice is to use an individual or organization namespace.

It allows distribution authors to release projects early.

And it doesn't block future changes. When a project becomes mature, and if it
appears there is no reason to keep individual ownership, :ref:`it remains
possible to rename the project<packagenames-rename>`.

Avoid deep nesting
==================

`The Zen of Python`_ says:

   Flat is better than nested.

Two levels is almost always enough
----------------------------------

Don't define everything in deeply nested hierarchies: you will end up with
distributions and packages like "pythonsport.common.maps.forest". This type
of name is both verbose and cumbersome (e.g. if you have many imports from the
package).
Furthermore, big hierarchies tend to break down over time as the boundaries
between different packages blur.

The consensus is that two levels of nesting are preferred.

Yes: "pyranha"

Yes: "pythonsport.climbing"

Yes: "pythonsport.forestmap"

No: "pythonsport.maps.forest"

.. _`packagenames-othermetadata`:

Limited namespace levels, unlimited metadata
--------------------------------------------

Consider distribution names (with or without namespaces) as unique identifiers
on PyPI.
It is important that these identifiers remain human-readable.
It is even better when these identifiers are meaningful.
But their primary purpose is not to classify or describe distributions.

As examples, if you only look at the name:

* you can't guess "nose" is about testing,
* or "celery" about distributed task queueing,
* or that "lettuce" is about tests, and has nothing in common with "celery".

The examples above are not problematic.

**`Classifiers`_ and keywords metadata are made for categorization of
distributions.**

As an example, there is a "Framework :: TurboGears" classifier. Even if names
are quite heterogeneous (they don't follow a pattern like collective.* for
Plone community projects), we get the list.

In order to `Organize community contributions`_, conventions about names and
namespaces matter, but conventions about metadata should be even more
important.

As an example, we can find Plone portlets in many places:

* plone.portlet.*
* collective.portlet.*
* collective.portlets.*
* collective.*.portlets
* some vendor-related distributions such as "quintagroup.portlet.cumulus"
* and even distributions where "portlet" pattern doesn't appear...

Even if Plone community has conventions, using the name to categorize
distributions is inapropriate. It's impossible to get the full list of
distributions that provide portlets for Plone by filtering on names.
But it would be possible if all these distributions used "Framework :: Plone"
classifier and "portlet" keyword.

Do you really need 3 levels?
----------------------------

For example, we have ``plone.principalsource`` instead of
``plone.source.principal`` or something like that. The name is shorter, the
package structure is simpler, and there would be very little to gain from
having three levels of nesting here. It would be impractical to try to put all
"core Plone" sources (a source is kind of vocabulary) into the
``plone.source.*`` namespace, in part because some sources are part of other
packages, and in part because sources already exist in other places. Had we
made a new namespace, it would be inconsistently used from the start.

3 levels are also tempting when:

* you are pluging into a community namespace, such as "collective".
* and you want to add a more restrictive "ownership" level, to avoid clashes
   inside the community.

In such a case, you'd better use the most restrictive ownership level as first
level.

As an example, where "collective" is a major community namespace that
"gergovie" belongs to, and "vercingetorix" it the name of "gergovie" author:

No: "collective.vercingetorix.gergovie"

Yes: "vercingetorix.collectivegergovie"

3 levels are supported for historical reasons
---------------------------------------------

Even if not recommended, 3 levels are supported. This is mainly for historical
reasons: 3 levels can be accepted where top level namespace owner explicitely
allows it with a specific convention. See `Organize community contributions`_
for details.

Don't use more than 3 levels
----------------------------

* 1 or 2 levels are recommended.
* 3 levels are discouraged, but supported for historical reasons.
* you shouldn't need more than 3 levels.

.. note::

    Even communities where namespaces are standard don't use more than 3 levels.

.. _`packagenames-organizecommunities`:

Organize community contributions
================================

Actions:

* Choose a naming convention for community contributions.

* If it is not :ref:`the default<packagenames-contribnamespace>`, document it.

   * if you use the :ref:`default convention<packagenames-contribnamespace>`,
     this document should be enough. Don't reapeat it. You MAY reference it.

   * else, tell users about custom conventions in project's "contribute" or
     "create modules" documentation.

* Also recommend the use of additional metadata, such as :ref:`classifiers and
   keywords<packagenames-othermetadata>`.

About convention choices:

* New projects SHOULD choose the default scheme.

* Existing projects with community contributions CAN start with custom
   conventions. Then they SHOULD `Promote migrations`_.

   It means that existing community conventions doesn't need to be changed.
   But they need to be explicitely documented: first state about current naming
   conventions, then about future.

Example: "pyranha" is your project name, distribution name and package name.
Tell contributors that:

* pyranha-related distributions should use the "pyranha" keyword

* pyranha distributions providing templates should also use "templates"
   keyword.

* community contributions should be released under "pyranhacontrib" namespace
   (i.e. use "pyranhacontrib.*" pattern):

.. _`packagenames-contribnamespace`:

Community contributions SHOULD use "${DIST}contrib.*" pattern
================================================================

The idea is to use a standard pattern to store community contributions for any
product or framework.

It is the simplest way to `Organize community contributions`_: the obvious way
to go is "${DIST}contrib", no ambiguity.

As an example:

* you are the author of "pyranha" project. You own the "pyranha" namespace.
* a third-party developer wants to publish a "giantteeth" project related to
   your "pyranha" project. He can publish it as "pyranhacontrib.giantteeth".

.. note::

    Why ``${DIST}contrib.*`` pattern?

    * ``${DIST}c.*`` is not explicit enough. As examples, "zc" belongs to
      "Zope Corporation" whereas "z3c" belongs to "Zope 3 community".

    * ``${DIST}community`` is too long.

    * ``${DIST}community`` conflicts with existing namespaces such as
      "iccommunity" or "PyCommunity".

    * ``${DIST}.contrib`` is inside ${DIST} namespace, i.e. it is owned by
      ${DIST} authors. It breaks the `Top level namespace relates to code
      ownership`_.

    * ``${DIST}.contrib.*`` breaks the `Avoid deep nesting`_ rule.

    * names where ``${DIST}`` doesn't appear are not explicit enough, i.e.
      nobody can guess they are related to ``${DIST}``.

    * ``{$DIST}contrib.*`` may conflict with existing ``sphinxcontrib-*``
      packages. But ``sphinxcontrib-*`` is actually about Sphinx contrib, so
      this is not a real conflict... In fact, the "contrib" suffix was inspired
      by "sphinxcontrib".


*******
Recipes
*******

How to avoid duplicate names
============================

Before you choose a distribution name, make sure it hasn't already been
registered in the following locations:

* `PyPI`_
* Popular code repositories such as:

   * `Github`_
   * `Bitbucket`_
   * `Gitorious`_

* `djangopackages.com`_

.. note:: A web service would be welcome for this!

Also make sure the package name hasn't already been registered:

* in the `Python Standard Library`_,
* in the locations where you checked for distribution name availability.

.. _`packagenames-rename`:

Renaming howto
==============

Renaming a project is possible, but keep in mind that it will cause some
confusions. So, pay particular attention to README and documentation, so that
users understand what happened.

#. First of all, **do not remove legacy distribution from PyPI**. Because some
    users may be using it.

#. Copy the legacy project, then change names (project, distribution and
    package/module). Pay attention to, at least:

    * packaging files,
    * folder name that contains source files,
    * documentation, including README,
    * import statements in code.

#. Assign ``Obsoletes-Dist`` metadata to new distribution in setup.cfg file.
    See `PEP 345 about Obsolete-Dist`_ and :ref:`setup.cfg specification
    <setupcfg-spec>`.

#. Release the renamed distribution as a new version, then publish it.

#. Edit legacy distribution:

    * add dependency to new distribution,
    * drop everything except packaging stuff,
    * add the ``Development Status :: 7 - Inactive`` classifier in setup script,
    * publish a new release.

So, users of the legacy package:

* can continue using the legacy distribution at a deprecated version,
* can upgrade to last version of legacy distribution, which is empty, ...
* ... and automatically download new distribution as a dependency of the legacy
   one.

Users who discover the legacy distribution see it is inactive.


**********
References
**********

.. target-notes::

.. _`Martin Aspeli's article about names`:
    http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and-namespaces
.. _`PEP 1`: http://www.python.org/dev/peps/pep-0001/
.. _`The Zen of Python`: http://www.python.org/dev/peps/pep-0020/
.. _`PEP 8`: http://www.python.org/dev/peps/pep-0008/#package-and-module-names
.. _`PEP 345`: http://www.python.org/dev/peps/pep-0345/
.. _`PEP 420`: http://www.python.org/dev/peps/pep-0420/
.. _`PEP 3108`: http://www.python.org/dev/peps/pep-3108
.. _`The Hitchhiker's Guide to Packaging`:
    http://guide.python-distribute.org/specification.html#naming-specification
.. _`in development official packaging documentation`:
    http://docs.python.org/dev/packaging/
.. _`plone`: http://plone.org/community/develop
.. _`django`: http://djangoproject.com/
.. _`pyramid`: http://pylonsproject.org
.. _`pypi`: http://pypi.python.org
.. _`django-debug-toolbar`:
    https://github.com/django-debug-toolbar/django-debug-toolbar
.. _`gp.fileupload`: http://pypi.python.org/pypi/gp.fileupload/
.. _`zest.releaser`: http://pypi.python.org/pypi/zest.releaser/
.. _`sphinx`: http://sphinx.pocoo.org
.. _`Classifiers`: http://pypi.python.org/pypi?:action=list_classifiers
.. _`collective.recaptcha`: http://pypi.python.org/pypi/collective.recaptcha/
.. _`Python community`: http://www.python.org/community/
.. _`pipeline`: http://pypi.python.org/pypi/pipeline/
.. _`python-pipeline`: http://pypi.python.org/pypi/python-pipeline/
.. _`django-pipeline`: http://pypi.python.org/pypi/django-pipeline/
.. _`setuptools`: http://pypi.python.org/pypi/setuptools
.. _`distribute`: http://packages.python.org/distribute/
.. _`Pillow`: http://pypi.python.org/pypi/Pillow/
.. _`PIL`: http://pypi.python.org/pypi/PIL/
.. _`Python Standard Library`: http://docs.python.org/library/index.html
.. _`github`: https://github.com
.. _`bitbucket`: https://bitbucket.org
.. _`gitorious`: https://gitorious.org/
.. _`djangopackages.com`: http://djangopackages.com
.. _`PEP 345 about Obsolete-Dist`:
    http://www.python.org/dev/peps/pep-0345/#obsoletes-dist-multiple-use



From erik.m.bray at gmail.com  Thu May 31 17:24:25 2012
From: erik.m.bray at gmail.com (Erik Bray)
Date: Thu, 31 May 2012 11:24:25 -0400
Subject: [Distutils] Requires-Dist: unittest2; 'test' in extras
In-Reply-To: <CALeMXf4bJvGCzJKip+ypS-v_U_=AU-5=PzRHmQ_cnh1gS252Sg@mail.gmail.com>
References: <CAG8k2+4SJP9CSLGyWweOZtASkum=gVTZ4FyNvNij7-zsEz=5MQ@mail.gmail.com>
	<CAG8k2+6c4i_Qs20VfVT1Ae4OoC8xeaHT-jYPtDPdmBO_wTC5NQ@mail.gmail.com>
	<CALeMXf4bJvGCzJKip+ypS-v_U_=AU-5=PzRHmQ_cnh1gS252Sg@mail.gmail.com>
Message-ID: <CAOTD34Y_sVMe9w6=hdGBpfo7dF4biPETvDUt-xSGO0YwPHozfQ@mail.gmail.com>

On Wed, May 30, 2012 at 5:35 PM, PJ Eby <pje at telecommunity.com> wrote:
> On Wed, May 30, 2012 at 3:09 PM, Daniel Holth <dholth at gmail.com> wrote:
>>
>> It looks like you can only install one extra at a time,
>
>
> Actually, you can specify more than one, using commas.? e.g. "easy_install
> foo[testing,c-extensions,celery-support,...]".

Would we want this to look the same way for pysetup?  Something like
`pysetup install foo[tests,docs]`?  That would be a pretty nice way to
handle docs, tests, and other miscellaneous extra requirements.  I
like the idea of using environment markers for that and not having to
add any new metadata fields.

Using an environment marker might also work for some kind of
build-requires, though support for that would still require some
special machinery.

Erik

From pje at telecommunity.com  Thu May 31 18:00:03 2012
From: pje at telecommunity.com (PJ Eby)
Date: Thu, 31 May 2012 12:00:03 -0400
Subject: [Distutils] conventions or best practice to choose package
	names?
In-Reply-To: <4FC69AE4.10904@marmelune.net>
References: <4FB02B36.8040504@marmelune.net>
	<CAPDm-FgW_QjVWV30SdYTvnXZzCeDYg=vTpwVjVsBKraVjZeEiw@mail.gmail.com>
	<4FC69AE4.10904@marmelune.net>
Message-ID: <CALeMXf5oPPFwZduiPWsaubp=LjEPOd-xnAwLANYNvUn+TMdpog@mail.gmail.com>

You've definitely put in a lot of work on this, and most of the actual
guidelines in your PEP are quite good.  I think there's a core part of this
that can and should be a good Informational-track PEP.

However, I do have a few comments regarding overall organization, and some
regarding some of the specific recommendations and tone.

In order of appearance in the PEP, they are:

1. I would strongly suggest striking the aside on eggs entirely -- there's
no point to bringing it up just to dismiss it, and there never was such a
thing as an "egg name" - eggs are just another kind of distribution, so
they don't need a special term.

2. A project name isn't the name of a directory, it's the name of the thing
you release distributions of.  E.g., my "Importing" project on PyPI (
http://pypi.python.org/pypi/Importing), which has the following names:

a) Project name = Importing
b) Release = 1.10
c) Distribution = Importing-1.10.zip
d) Module = peak.util.imports

Following this conceptual breakdown will make the naming recommendations
easier to follow.

3. The rationale is unnecessary and could (and *should*) be cut entirely.
Use PEP 8 as a model - it doesn't waste time explaining why coding
guidelines are a good idea.  The truth is, your PEP would be massively
improved simply by deleting this entire section and not even trying to
replace it with anything.

4. The proposal section is also unnecessary, and likely to produce
resistance in any event.  There is no reason why every package should use
your approach, and some developers will be opposed to your conventions.  (I
disagree with some of them myself, for that matter, as I will discuss
below.)  Some of the material from this section might make a good later
section on "How to apply these guidelines to your project".

5. The actual guidelines are pretty good, as I said.  In particular, I like
pretty much every thing you say about package names.  I disagree with some
of your assertions regarding project names, however.  It's true that a
project name doesn't need to spell out what a project does (as with Celery,
Nose, etc.), but it does in fact hurt discovery and use when people use
package-based project names.  It's a continuing source of frustration, for
example, that buildout recipe projects have names like z3c.recipe.scripts
and other names that I can't ever remember, and am forced to re-google or
dig up previous buildout files to find the magic names to include in my
buildouts.  To me, the  important thing about a project name is that it be
*memorable*, and that argues against using namespaced package names as
project names for contributions to a larger project, such as Plone
portlets, Buildout recipes, etc.

This isn't a huge point of contention for me, I just want to point out that
the good naming choices for projects are more complicated than "just use
the package name and let people search for it".  I think there are some
other points you made that are a little too cut-and-dried in the same way,
but this is the only really big one.

6. Drop the language about how things are supported or not supported.  This
just isn't true: Python the language supports you nesting things 6 layers
deep if you feel like it, and AFAIK there are no plans to change that, nor
should there be.  Stick to talking here about what is or isn't a good idea,
not what's supported or not supported.  That's just FUD.

7.  PyPI should be the only place people have to check for a registered
distribution name; authors of projects that are hosted elsewhere can and
should use "setup.py register" to claim the name, or log on and do it.

Anyway,  as I said, I think you've got some really good stuff here, but
it's got a lot of other stuff hiding it.  Cut away the extras (and the
parts implying these guidelines are mandatory) and you've got a good
Informational-track PEP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120531/add7e4ca/attachment.html>

From pje at telecommunity.com  Thu May 31 18:04:32 2012
From: pje at telecommunity.com (PJ Eby)
Date: Thu, 31 May 2012 12:04:32 -0400
Subject: [Distutils] Requires-Dist: unittest2; 'test' in extras
In-Reply-To: <CAOTD34Y_sVMe9w6=hdGBpfo7dF4biPETvDUt-xSGO0YwPHozfQ@mail.gmail.com>
References: <CAG8k2+4SJP9CSLGyWweOZtASkum=gVTZ4FyNvNij7-zsEz=5MQ@mail.gmail.com>
	<CAG8k2+6c4i_Qs20VfVT1Ae4OoC8xeaHT-jYPtDPdmBO_wTC5NQ@mail.gmail.com>
	<CALeMXf4bJvGCzJKip+ypS-v_U_=AU-5=PzRHmQ_cnh1gS252Sg@mail.gmail.com>
	<CAOTD34Y_sVMe9w6=hdGBpfo7dF4biPETvDUt-xSGO0YwPHozfQ@mail.gmail.com>
Message-ID: <CALeMXf4qSOayywDPe+N4Mp9uP1HL4ku_vXq-w52jGUP-eThiKA@mail.gmail.com>

On Thu, May 31, 2012 at 11:24 AM, Erik Bray <erik.m.bray at gmail.com> wrote:

> On Wed, May 30, 2012 at 5:35 PM, PJ Eby <pje at telecommunity.com> wrote:
> > On Wed, May 30, 2012 at 3:09 PM, Daniel Holth <dholth at gmail.com> wrote:
> >>
> >> It looks like you can only install one extra at a time,
> >
> >
> > Actually, you can specify more than one, using commas.  e.g.
> "easy_install
> > foo[testing,c-extensions,celery-support,...]".
>
> Would we want this to look the same way for pysetup?  Something like
> `pysetup install foo[tests,docs]`?  That would be a pretty nice way to
> handle docs, tests, and other miscellaneous extra requirements.  I
> like the idea of using environment markers for that and not having to
> add any new metadata fields.
>
> Using an environment marker might also work for some kind of
> build-requires, though support for that would still require some
> special machinery.
>

Since I haven't used pysetup yet, I couldn't really say.  I can say that
some people have mentioned that they find setuptools' "extras" mechanism to
be confusing, unnecessary, or a tool in search of a usecase.  I'm not
terribly attached to them, but I prefer them to the solution that e.g.
Celery uses.  Celery has various dummy distributions on PyPI like
"celery-with-couchdb" that exist only to pull in extras, and it only needs
them because some packaging tools don't support extras.  (ISTR that pip
doesn't support them.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120531/082c93d2/attachment.html>

From dholth at gmail.com  Thu May 31 19:02:49 2012
From: dholth at gmail.com (Daniel Holth)
Date: Thu, 31 May 2012 13:02:49 -0400
Subject: [Distutils] Requires-Dist: unittest2; 'test' in extras
In-Reply-To: <CALeMXf4qSOayywDPe+N4Mp9uP1HL4ku_vXq-w52jGUP-eThiKA@mail.gmail.com>
References: <CAG8k2+4SJP9CSLGyWweOZtASkum=gVTZ4FyNvNij7-zsEz=5MQ@mail.gmail.com>
	<CAG8k2+6c4i_Qs20VfVT1Ae4OoC8xeaHT-jYPtDPdmBO_wTC5NQ@mail.gmail.com>
	<CALeMXf4bJvGCzJKip+ypS-v_U_=AU-5=PzRHmQ_cnh1gS252Sg@mail.gmail.com>
	<CAOTD34Y_sVMe9w6=hdGBpfo7dF4biPETvDUt-xSGO0YwPHozfQ@mail.gmail.com>
	<CALeMXf4qSOayywDPe+N4Mp9uP1HL4ku_vXq-w52jGUP-eThiKA@mail.gmail.com>
Message-ID: <CAG8k2+751X9hdBDjfUGvOGAvGQ8ZozN+bOJZLJwo6EZmFuLYcA@mail.gmail.com>

I will implement

Requires-Dist: somedist; extra == 'name'

and consider install package[extra1, extra2] to be sugar for install
package package[extra1] package[extra2]

It is easier to maintain a precomputed key : requirements mapping that way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120531/66a004c4/attachment.html>

From carl at oddbird.net  Thu May 31 19:48:31 2012
From: carl at oddbird.net (Carl Meyer)
Date: Thu, 31 May 2012 10:48:31 -0700
Subject: [Distutils] Requires-Dist: unittest2; 'test' in extras
In-Reply-To: <CALeMXf4qSOayywDPe+N4Mp9uP1HL4ku_vXq-w52jGUP-eThiKA@mail.gmail.com>
References: <CAG8k2+4SJP9CSLGyWweOZtASkum=gVTZ4FyNvNij7-zsEz=5MQ@mail.gmail.com>
	<CAG8k2+6c4i_Qs20VfVT1Ae4OoC8xeaHT-jYPtDPdmBO_wTC5NQ@mail.gmail.com>
	<CALeMXf4bJvGCzJKip+ypS-v_U_=AU-5=PzRHmQ_cnh1gS252Sg@mail.gmail.com>
	<CAOTD34Y_sVMe9w6=hdGBpfo7dF4biPETvDUt-xSGO0YwPHozfQ@mail.gmail.com>
	<CALeMXf4qSOayywDPe+N4Mp9uP1HL4ku_vXq-w52jGUP-eThiKA@mail.gmail.com>
Message-ID: <4FC7AEEF.4090802@oddbird.net>

On 05/31/2012 09:04 AM, PJ Eby wrote:
> Since I haven't used pysetup yet, I couldn't really say.  I can say that
> some people have mentioned that they find setuptools' "extras" mechanism
> to be confusing, unnecessary, or a tool in search of a usecase.  I'm not
> terribly attached to them, but I prefer them to the solution that e.g.
> Celery uses.  Celery has various dummy distributions on PyPI like
> "celery-with-couchdb" that exist only to pull in extras, and it only
> needs them because some packaging tools don't support extras.  (ISTR
> that pip doesn't support them.)

Pip supports extras since version 1.1, released a couple months ago. FWIW.

Carl

-------------- 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/20120531/6fccb580/attachment-0001.pgp>