headers
Tarek Ziadé | 1 Jul 2009 01:34
Picon
Gravatar

Re: PEP 376

On Wed, Jul 1, 2009 at 12:47 AM, Steven D'Aprano<steve <at> pearwood.info> wrote:
> On Wed, 1 Jul 2009 05:19:07 am Tarek Ziadé wrote:
>> 2009/6/30 Guido van Rossum <guido <at> python.org>:
> ...
>> > So what *is* the distutils-sig consensus?
>>
>> The consensus is to have one and only one way to install
>> distributions in Python,
>
> "One and only one way"? Shouldn't that be "one obvious way"?
>
> There is a big difference -- the first implies that Python should
> actively prohibit (somehow!) or at least inhibit any other install
> mechanisms, while the second implies that there should be a preferred,
> obvious, but not compulsory, mechanism.
>
> If you say "one and only one", and I take you at your word, then I can
> only assume that you want to actively prevent me from manually
> dropping .py files into my PYTHONPATH and having them work. I would
> guess that's probably not what you mean, but that's what it sounds like
> you're proposing. I don't like guessing -- would you please clarify
> what you mean?

one and only one way to install a distribution using its setup.py script,
among the ways provided by easy_install, distutils and pip.
e.g. avoiding having different format/location for the generated .egg.info;

>
>
> Some questions and comments regarding the PEP:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tarek Ziadé | 1 Jul 2009 01:46
Picon
Gravatar

Re: PEP 376

On Tue, Jun 30, 2009 at 10:06 PM, Scott David
Daniels<Scott.Daniels <at> acm.org> wrote:
> Tarek Ziadé wrote:
>>
>> On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore<p.f.moore <at> gmail.com> wrote:
>>>
>>> [1] I'd actually like it if the PEP defined an uninstall command -
>>> something like "python -m distutils.uninstall packagename". It can be
>>> as minimalist as you like, but I'd like to see it present.
>>
>> it's already there:
>>
>> http://www.python.org/dev/peps/pep-0376/#adding-an-uninstall-function
>
> That (at least as I read it) is a function, not a command.
> If it is a command, give an example of its use from the command line
> for us poor "don't want to research" people.  If the following works:
>
>    $ python setup.py uninstall some_package
>
> Then explicitly say so for us poor schlubs.
>

Right, I'll add that. Although it will be a reference implementation only.
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply | 17 comments |
headers
Tarek Ziadé | 1 Jul 2009 01:49
Picon
Gravatar

Re: PEP 376

On Tue, Jun 30, 2009 at 11:11 PM, Nick Coghlan<ncoghlan <at> gmail.com> wrote:
>>
>>
>> previous formats will not be supported but that won't break anything
>> of course since the new APIs will work only over the distribution
>> installed with the new version of distutils.
>
> To address PJE's question in the PEP, it may be worth expanding on this
> in the backwards compatibility section explaining how the new distutils
> metadata system avoids getting confused by the old pre-standardisation
> installation formats (e.g. it may be that the directory names and/or
> filenames all deliberately differ from current approaches precisely so
> they can coexist without interfering with each other)
>

I'll work on making it clearer,

> Also, I find the following paragraph (near the start of the section
> linked above) confusing:
>
> [PEP 376]
>> Notice that this change is based on the standard proposed by
>> EggFormats, although this standard proposes two ways to install
>> files:
>>
>> * A self-contained directory that can be zipped or left unzipped and
>> contains the distribution files and the .egg-info directory.
>> * A distinct .egg-info directory located in the site-packages directory.
>
> This is unclear as to what "this standard" is referring to (since the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tarek Ziadé | 1 Jul 2009 02:07
Picon
Gravatar

Re: PEP 376

On Tue, Jun 30, 2009 at 10:11 PM, Paul Moore<p.f.moore <at> gmail.com> wrote:
>> We said during the summit at Pycon that we wanted this feature in
>> Distutils, (Guido said so)
>
> "We" in this context denotes the people at the summit. Please remember
> that people who weren't there still have an opinion - and it may well
> differ. I'm not saying that it *does* differ, just that the view of
> the summit should not be viewed as conclusive (unless the way Python
> is developed is very different from how I understand it).

Sorry I didn't mean it this way.  The summit was just the kickoff for this PEP,
but with the strong desire to have a standard + some API for it.

Also, notice that I put in "We" also the people that answered the survey
I did before the summit.
(http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/)

I'll make other fixes in the PEP with the feedback you gave, thanks

Tarek
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
P.J. Eby | 1 Jul 2009 02:13
Gravatar

Re: PEP 376

At 01:34 AM 7/1/2009 +0200, Tarek Ziadé wrote:
>On Wed, Jul 1, 2009 at 12:47 AM, Steven D'Aprano<steve <at> pearwood.info> wrote:
> > I don't see how this proposal will help in the second case. If you
> > install distribution Spam, containing file spam.py, and then install
> > distribution Ham, which requires spam.py, what is to prevent you from
> > removing Spam and breaking Ham?
> >
> > If you don't propose a solution for the dependency problem, you should
> > say so.
>
>This problem is solved as described later in the PEP, with the API
>that allows you to get the
>list of the distributions that use a given file. (thanks to the RECORD files)
>
>If Spam and Ham use smap.py, and if you uninstall Spam, this file will
>not be removed
>because the API will tell you its used in both distributions.

That's not the scenario he's talking about.  He's talking about the 
case where Ham has an 'install_requires' of Spam.  That is, a runtime 
dependency, not a shared file.

>Good question, I have never created such distribution.
>Aren't they read-only files ?

setuptools' bdist_egg command has an option to exclude source from an 
.egg, but it doesn't do anything special with permissions.  I don't 
think any other current install tools support source-free installation.

_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
P.J. Eby | 1 Jul 2009 02:21
Gravatar

Re: PEP 376

At 07:11 AM 7/1/2009 +1000, Nick Coghlan wrote:
>To address PJE's question in the PEP, it may be worth expanding on this
>in the backwards compatibility section explaining how the new distutils
>metadata system avoids getting confused by the old pre-standardisation
>installation formats (e.g. it may be that the directory names and/or
>filenames all deliberately differ from current approaches precisely so
>they can coexist without interfering with each other)

In particular, it should be explicitly noted that the API does not 
support .egg files (or directories), and thus cannot substitute for 
the pkg_resources API, as far as detecting installed packages.

That is, users who need to unequivocally detect the presence/version 
of a project on sys.path, etc. will still have to use pkg_resources.

(Because pkg_resources supports the format proposed by the PEP, but 
the PEP does not support .egg files and directories.)

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Tarek Ziadé | 1 Jul 2009 02:19
Picon
Gravatar

Re: PEP 376

2009/7/1 P.J. Eby <pje <at> telecommunity.com>:
> At 01:34 AM 7/1/2009 +0200, Tarek Ziadé wrote:
>>
>> On Wed, Jul 1, 2009 at 12:47 AM, Steven D'Aprano<steve <at> pearwood.info>
>> wrote:
>> > I don't see how this proposal will help in the second case. If you
>> > install distribution Spam, containing file spam.py, and then install
>> > distribution Ham, which requires spam.py, what is to prevent you from
>> > removing Spam and breaking Ham?
>> >
>> > If you don't propose a solution for the dependency problem, you should
>> > say so.
>>
>> This problem is solved as described later in the PEP, with the API
>> that allows you to get the
>> list of the distributions that use a given file. (thanks to the RECORD
>> files)
>>
>> If Spam and Ham use smap.py, and if you uninstall Spam, this file will
>> not be removed
>> because the API will tell you its used in both distributions.
>
> That's not the scenario he's talking about.  He's talking about the case
> where Ham has an 'install_requires' of Spam.  That is, a runtime dependency,
> not a shared file.

Ah, right sorry I misunderstood... They are no plans to handle
dependency installation / uninstallation / managment  at distutils
level.
so if you remove Ham, it will not check what distributions use it. So
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Teague | 1 Jul 2009 04:12
Picon
Gravatar

Re: PEP 376


On Jun 30, 2009, at 4:46 PM, Tarek Ziadé wrote:

> On Tue, Jun 30, 2009 at 10:06 PM, Scott David
> Daniels<Scott.Daniels <at> acm.org> wrote:
>> Tarek Ziadé wrote:
>>>
>>> On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore<p.f.moore <at> gmail.com>  
>>> wrote:
>>>>
>>>> [1] I'd actually like it if the PEP defined an uninstall command -
>>>> something like "python -m distutils.uninstall packagename". It  
>>>> can be
>>>> as minimalist as you like, but I'd like to see it present.
>>>
>>> it's already there:
>>>
>>> http://www.python.org/dev/peps/pep-0376/#adding-an-uninstall- 
>>> function
>>
>> That (at least as I read it) is a function, not a command.
>> If it is a command, give an example of its use from the command line
>> for us poor "don't want to research" people.  If the following works:
>>
>>    $ python setup.py uninstall some_package
>>
>> Then explicitly say so for us poor schlubs.
>>
>
> Right, I'll add that. Although it will be a reference implementation
(Continue reading)

Permalink | Reply | 13 comments |
headers
Scott David Daniels | 1 Jul 2009 05:06
Picon
Favicon

Re: PEP 376

Kevin Teague wrote:
> On Jun 30, 2009, at 4:46 PM, Tarek Ziadé wrote:
>> On Tue, Jun 30, 2009 at 10:06 PM, Scott David
>> Daniels<Scott.Daniels <at> acm.org> wrote:
>>> Tarek Ziadé wrote:
>>>> On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore<p.f.moore <at> gmail.com> wrote:
>>>>> [1] I'd actually like it if the PEP defined an uninstall command -
>>>>> something like "python -m distutils.uninstall packagename". It can be
>>>>> as minimalist as you like, but I'd like to see it present.
>>>> it's already there:
>>>> http://www.python.org/dev/peps/pep-0376/#adding-an-uninstall-function
>>> That (at least as I read it) is a function, not a command.
>>> If it is a command, give an example of its use from the command line
>>> for us poor "don't want to research" people.  If the following works:
>>>    $ python setup.py uninstall some_package
>>> Then explicitly say so for us poor schlubs.
>> Right, I'll add that. Although it will be a reference implementation 
>> only.
> Uninstall as a command feels a little weird....
> I dunno what the right solution is. My two-cents is either to punt and 
> only include an uninstall function as currently proposed, or for only 
> supporting some form of the "python setup.py uninstall" style....

But for us poor schlubs, we want you brilliant packagers to actually
come to a hard decision.  If you want approval either admit you have no
solution in the PEP (and detail the issues that prevent a decision),
provide a minimally acceptable command, or expect that nobody sees the
value of what you propose....

--Scott David Daniels
(Continue reading)

Permalink | Reply | 5 comments |
headers
Guido van Rossum | 1 Jul 2009 06:09
Favicon

Re: PEP 376

2009/6/30 Guido van Rossum <guido <at> python.org>:
> On Tue, Jun 30, 2009 at 5:32 AM, Nick Coghlan<ncoghlan <at> gmail.com> wrote:
>> Martin v. Löwis wrote:
>>>> If no one objects, I'd like to push PEP 376 in the "accepted" status
>>>> and go ahead with its implementation,
>>>> with continuous feedback at Distutils-SIG as we did to build it.
>>>
>>> I think this isn't quite the process. In the past, every PEP required
>>> BDFL pronouncement, which you should now seek.
>>
>> Agreed. While Guido is highly likely to just accept the distutils-sig
>> consensus on something like this, that doesn't eliminate the need for
>> him to actually *say* that he is approving the PEP on that basis.
>
> Sure. :-)
>
> So what *is* the distutils-sig consensus?
>
> And is there consensus outside of it? (Remember the ipaddr debacle.
> It's easy for people to miss an important PEP.)

Looks like the discussion isn't quite over yet...

I did read about a third of the PEP but still feel pretty lost about
how it all fits together; I won't have time to read more until next
week, probably. I made some minor edits for typos and grammar (being
PEP editor and all :-).

I noted an inconsistency: first you say that the RECORD file uses the
excel dialect, but at the end of the same section you say it uses the
(Continue reading)

Permalink | Reply | 3 comments |

Gmane