Paul Moore wrote:
> 2009/7/7 Ben Finney :
>>> - PEP 376 is an opportunity to consider cleanup
>>> - there are some strong supporters of keeping things
>>> setuptools-compatible
>> Your implication seems to be that these two are incompatible. It should
>> be noted that it's possible to clean up, by
2009/7/7 Ben Finney :
>> - PEP 376 is an opportunity to consider cleanup
>> - there are some strong supporters of keeping things
>> setuptools-compatible
>
> Your implication seems to be that these two are incompatible. It should
> be noted that it's possible to clean up, by having a separate (e.g.
Paul Moore writes:
> I agree the current situation is a mess. I believe that everything you
> mention is related to setuptools - so essentially, we have the
> situation:
>
> - the existing setuptools format is a mess (at least in the opinion of
> MAL and me :-))
No argument from me on this poin
2009/7/7 M.-A. Lemburg :
> Well I've added another one above, the pre-built approach :-)
Thanks! That's a lot of help. Are there any public examples, or is
your format only used internally?
Would you expect to use any of the new pkgutil APIs - for example, to
check if a distribution is installed,
On Tue, Jul 7, 2009 at 11:28 AM, M.-A. Lemburg wrote:
>
> Writing an uninstall command really isn't all that hard, provided
> you stick with the standard distutils "python setup.py install"
> dance. The whole packaging approach only complicates things, IMHO.
You can't expect people to keep the dis
Paul Moore wrote:
> 2009/7/7 M.-A. Lemburg :
>> The PEP should take the chance to define not only the
>> directory, but also the complete set of files in there and
>> their format.
>>
>> A typical setuptools dir looks like this:
>>
>> dependency_links.txt
>> namespace_packages.txt
>> not-zip-safe
>
2009/7/7 M.-A. Lemburg :
> The PEP should take the chance to define not only the
> directory, but also the complete set of files in there and
> their format.
>
> A typical setuptools dir looks like this:
>
> dependency_links.txt
> namespace_packages.txt
> not-zip-safe
> PKG-INFO
> requires.txt
> SO
On 6 Jul, 2009, at 9:53, Tarek Ziadé wrote:
2009/7/6 Ronald Oussoren :
I'm -1 on changing the name. For better or worse setuptools is the
elephant
in the room w.r.t. package management and it would IMHO be better
to stay
compatible (even if the stdlib only implements a subset of
setuptools
Paul Moore wrote:
> 2009/7/7 Ben Finney :
>> Paul Moore writes:
>>
>>> In fact, the above strongly suggests to me that PEP 376 must NOT
>>> follow setuptools conventions - otherwise, it will end up clashing
>>> with the files setuptools is putting on my system.
>> I think the argument for a separa
On Tue, Jul 7, 2009 at 12:16 AM, Paul Moore wrote:
>>
>> I believe the idea of having different names in 2.x and 3.x would likely
>> cause too many problems for simple bdist_* installers of modules that
>> use only the common 2.x/3.x language subset, so I'm also -1 on that idea.
>
> That suits me t
2009/7/7 Ben Finney :
> Paul Moore writes:
>
>> In fact, the above strongly suggests to me that PEP 376 must NOT
>> follow setuptools conventions - otherwise, it will end up clashing
>> with the files setuptools is putting on my system.
>
> I think the argument for a separate ‘.pydist’ metadata di
Paul Moore writes:
> In fact, the above strongly suggests to me that PEP 376 must NOT
> follow setuptools conventions - otherwise, it will end up clashing
> with the files setuptools is putting on my system.
I think the argument for a separate ‘.pydist’ metadata directory,
normative in PEP 376,
2009/7/6 Nick Coghlan :
> P.J. Eby wrote:
>> So, I'm +1 for no change (obviously), and +0 for "always .pydist in 3.x
>> and always .egg-info in 2.x", whether the latter part is achieved by
>> making distutils/pkgutil use a version-dependent extension, or by
>> refusing to backport distutils/pkgutil
P.J. Eby wrote:
> So, I'm +1 for no change (obviously), and +0 for "always .pydist in 3.x
> and always .egg-info in 2.x", whether the latter part is achieved by
> making distutils/pkgutil use a version-dependent extension, or by
> refusing to backport distutils/pkgutil to 2.x. I'm -1 for having
>
At 07:15 PM 7/6/2009 +0100, Paul Moore wrote:
My point was that distributions which use setuptools in their
setup.py, *even if there's no runtime dependency on setuptools* end up
with non-standard .egg-info's. There is no good reason for this, from
my POV as a package user. So if setuptools is br
2009/7/6 P.J. Eby :
> At 07:18 PM 7/6/2009 +0200, Tarek Ziadé wrote:
>>
>> >> So is PEP 376 going to be able to cope with the stuff I have installed
>> >> at the moment? If not, what's the point???
>> >
>> > If I understand Tarek's proposal correctly, then no, it will not cope.
>>
>> Why that ? Can
2009/7/6 P.J. Eby :
> At 04:14 PM 7/6/2009 +0100, Paul Moore wrote:
>> This is getting confusing. Is Phillip saying that setuptools will cope
>> with the file changing to a directory without modification, but it
>> can't handle a change in the name?
>
> The existing versions of setuptools will read
At 07:18 PM 7/6/2009 +0200, Tarek Ziadé wrote:
>> So is PEP 376 going to be able to cope with the stuff I have installed
>> at the moment? If not, what's the point???
>
> If I understand Tarek's proposal correctly, then no, it will not cope.
Why that ? Can you detail ? On a system that uses only
On Mon, Jul 6, 2009 at 6:58 PM, P.J. Eby wrote:
>> My site-packages has a confusing mix of egginfo directories and files.
>> Note that I NEVER use setuptools other than where an existing
>> package's setup.py requires it. In that case, I still only do python
>> setup.py bdist_wininst and install th
At 04:14 PM 7/6/2009 +0100, Paul Moore wrote:
2009/7/6 Nick Coghlan :
> P.J. Eby wrote:
>> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>> But if it's based on PEP 302 protocols and if the pkgutil code works
>>> with the sys.meta_path hook,
>>> setuptools could then provide its loader, based o
At 10:32 AM 7/6/2009 +0100, Paul Moore wrote:
I'm +0 on changing the name, as long as it's the *only* "do it this
way because setuptools isn't going to change" issue.
Please note that I never said that. I was the one who suggested
".pydist", remember?
I just don't want to have to complicate
On Mon, Jul 6, 2009 at 5:53 PM, Paul Moore wrote:
> 2009/7/6 Tarek Ziadé :
>> why can't we just go ahead and continue the work as we started with PEP 376,
>> introducing your work on PEP 302-like behavior.
>>
>> Then if we get a consensus on this PEP and introduce it in 2.7/3.2,
>> setuptools will
2009/7/6 Tarek Ziadé :
> why can't we just go ahead and continue the work as we started with PEP 376,
> introducing your work on PEP 302-like behavior.
>
> Then if we get a consensus on this PEP and introduce it in 2.7/3.2,
> setuptools will have to follow this consensus.
Essentially, because when
On Mon, Jul 6, 2009 at 5:14 PM, Paul Moore wrote:
> [...]
> And yet, given that PEP 376 is explicitly being designed with a goal
> being to act as the common standard that *all* package management
> formats can use, is it not the whole point that once it's defined and
> we have achieved consensus,
2009/7/6 Nick Coghlan :
> P.J. Eby wrote:
>> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>> But if it's based on PEP 302 protocols and if the pkgutil code works
>>> with the sys.meta_path hook,
>>> setuptools could then provide its loader, based on its EggFormats and
>>> act as a provider witho
P.J. Eby wrote:
> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>> But if it's based on PEP 302 protocols and if the pkgutil code works
>> with the sys.meta_path hook,
>> setuptools could then provide its loader, based on its EggFormats and
>> act as a provider without being broken.
>
> You misun
2009/7/6 Tarek Ziadé :
> 2009/7/6 Ronald Oussoren :
>> I'm -1 on changing the name. For better or worse setuptools is the elephant
>> in the room w.r.t. package management and it would IMHO be better to stay
>> compatible (even if the stdlib only implements a subset of
>> setuptools/pkg_resources)
2009/7/6 Ronald Oussoren :
> I'm -1 on changing the name. For better or worse setuptools is the elephant
> in the room w.r.t. package management and it would IMHO be better to stay
> compatible (even if the stdlib only implements a subset of
> setuptools/pkg_resources)
>
I'd rather see the elephan
2009/7/6 Paul Moore :
> 2009/7/6 P.J. Eby :
>> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>>
>>> But if it's based on PEP 302 protocols and if the pkgutil code works
>>> with the sys.meta_path hook,
>>> setuptools could then provide its loader, based on its EggFormats and
>>> act as a provider
I'm -1 on changing the name. For better or worse setuptools is the
elephant in the room w.r.t. package management and it would IMHO be
better to stay compatible (even if the stdlib only implements a subset
of setuptools/pkg_resources)
Ronald
On 5 jul 2009, at 23:10, Nick Coghlan wrote:
2009/7/6 P.J. Eby :
> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>
>> But if it's based on PEP 302 protocols and if the pkgutil code works
>> with the sys.meta_path hook,
>> setuptools could then provide its loader, based on its EggFormats and
>> act as a provider without being broken.
>
> You
But as I said earlier, if we use a PEP 302-like loader, distutils will
be able to consume
several loaders, so setuptools will be able to provide its storage
strategy (naming and egg dir locations)
So I don't understand why you are saying that it will be incompatible
or get confused.
2009/7/6 P.J
At 07:10 AM 7/6/2009 +1000, Nick Coghlan wrote:
By using a new name for the
directory we *guarantee* that old packaging utilities won't get confused
by the new format (they simply won't acknowledge its existence).
This is incorrect; they will get confused because they will think
that the relev
At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
But if it's based on PEP 302 protocols and if the pkgutil code works
with the sys.meta_path hook,
setuptools could then provide its loader, based on its EggFormats and
act as a provider without being broken.
You misunderstand me. The whole point o
Nick Coghlan writes:
> 'pydist': accurate, specific and without the disadvantages of the 'egg'
> jargon
>
> PJE points out that existing tools (setuptools, pip, etc) won't be
> compatible with the new format at all if it uses a new name, but I am
> having trouble seeing that as a *bad* thing. By
2009/7/5 P.J. Eby :
> At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>
>> The loader would still work with "DIST_NAME.egg-info" directories for
>> compatibility with
>> existing format in the query APIs, but the Distutils install command
>> would rather create "DIST_NAME.metadata"
>
> Note that t
Tarek Ziadé wrote:
> 2009/7/5 P.J. Eby :
>> If you want a
>> clearer name, '.pydist' or some such would at least be reasonably specific.
>> (It'd still have a backward compatibility problem, but at least then
>> there'd be some benefit to the name change.)
>
> I do find "DIST_NAME.metadata" well
2009/7/5 P.J. Eby :
> At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>
>> The loader would still work with "DIST_NAME.egg-info" directories for
>> compatibility with
>> existing format in the query APIs, but the Distutils install command
>> would rather create "DIST_NAME.metadata"
>
> Note that t
At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
The loader would still work with "DIST_NAME.egg-info" directories for
compatibility with
existing format in the query APIs, but the Distutils install command
would rather create "DIST_NAME.metadata"
Note that this would then break setuptools witho
On Sun, Jul 5, 2009 at 3:27 PM, Paul Moore wrote:
>>
>> A concrete proposal would be to take back your proposal, but return
>> tuples with the location as the first member.
>> e.g. "(location, relative path[s])"
>
> That sounds reasonable. So we can forget the "local" parameter, and
> return a tupl
2009/7/5 Tarek Ziadé :
> Agreed, the zip case was added afterwards, but in practice, the APIs are still
> dealing with the files are *filesystem files* located in a container (eg a
> directory
> or a zip file) located somewhere on the filesystem.
>
> "local" in that case is a flag that means "tran
On Sun, Jul 5, 2009 at 3:13 PM, Paul Moore wrote:
> 2009/7/5 Tarek Ziadé :
>> Go for it please, and let me know if you set a bitbucket account, so
>> you can push your commits in there directly
>
> My bitbucket account is 'pmoore'.
You're set.
___
Python
2009/7/4 Brett Cannon :
>>
>> P.S. +lots on using 'metadata' in the PEP 376 method names rather than
>> the jargon 'egginfo'. Jargon isn't always bad, but using it seems fairly
>> gratuitous in this case.
>
> Ditto from here. Plus I have an aversion to terminology that goes down the
> reptile route
2009/7/5 Tarek Ziadé :
> Go for it please, and let me know if you set a bitbucket account, so
> you can push your commits in there directly
My bitbucket account is 'pmoore'.
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
On Sat, Jul 4, 2009 at 3:04 PM, Paul Moore wrote:
> 2009/7/3 Tarek Ziadé :
>> 2009/7/3 Paul Moore :
>>> Does this sound sensible? Tarek, would you be OK with me attempting to
>>> modify your prototype to support this protocol? Are there any tests
>>> for PEP 376, so that I can confirm I haven't com
2009/7/4 Paul Moore :
> 2009/7/4 Paul Moore :
>> 2009/7/3 Tarek Ziadé :
>>> You can give me a bitbucket account so I can give you write access to the
>>> repo,
>>> There are tests as long as you install Nose.
>>
>> How do I get the tests to work? Just running nosetests gives an error
>> (probably
I'm not complaining, just saying I didn't notice. I essentially did the same
with get_source/get_bytecode so as to be able to set __file__.
When I get around to it I will create a RunpyLoader in importlib.abc and add
the method in the proper machinery loaders.
On Jul 4, 2009 3:43 PM, "Nick Coghla
Paul Moore wrote:
> 2009/7/4 Brett Cannon :
>>> (runpy is also a lot happier with
>>> them when they expose get_filename(), a relatively recent addition to
>>> the PEP 302 API).
>> An addition I was not even aware of. Looks like importlib needs a little
>> updating.
>
> Yes, I didn't notice that s
2009/7/4 Brett Cannon :
>> > Finder.uninstall(distribution_name, filter=callable, installer=name)
>> > Uninstall the given distribution. It's likely that many finders will
>> > be read-only. In that case, this function should return None.
>> > Otherwise, return a list of the "files" removed. (This
On Fri, Jul 3, 2009 at 17:47, Nick Coghlan wrote:
> Tarek Ziadé wrote:
> > 2009/7/3 Paul Moore :
> >> Does this sound sensible? Tarek, would you be OK with me attempting to
> >> modify your prototype to support this protocol? Are there any tests
> >> for PEP 376, so that I can confirm I haven't c
2009/7/4 Paul Moore :
> 2009/7/3 Tarek Ziadé :
>> You can give me a bitbucket account so I can give you write access to the
>> repo,
>> There are tests as long as you install Nose.
>
> How do I get the tests to work? Just running nosetests gives an error
> (probably because pkgutil is being import
2009/7/3 Tarek Ziadé :
> 2009/7/3 Paul Moore :
>> Does this sound sensible? Tarek, would you be OK with me attempting to
>> modify your prototype to support this protocol? Are there any tests
>> for PEP 376, so that I can confirm I haven't completely broken
>> something? If I can, I'll knock up som
2009/7/3 Tarek Ziadé :
> You can give me a bitbucket account so I can give you write access to the
> repo,
> There are tests as long as you install Nose.
How do I get the tests to work? Just running nosetests gives an error
(probably because pkgutil is being imported from the stdlib, rather
than
Tarek Ziadé wrote:
> 2009/7/3 Paul Moore :
>> Does this sound sensible? Tarek, would you be OK with me attempting to
>> modify your prototype to support this protocol? Are there any tests
>> for PEP 376, so that I can confirm I haven't completely broken
>> something? If I can, I'll knock up some si
2009/7/3 Paul Moore :
> Does this sound sensible? Tarek, would you be OK with me attempting to
> modify your prototype to support this protocol? Are there any tests
> for PEP 376, so that I can confirm I haven't completely broken
> something? If I can, I'll knock up some simple prototype importers
This post basically follows on from the previous thread about PEP 376
(Changing the .egg-info structure) where it was pointed out that the
PEP doesn't cover PEP 302 import hooks (except in the explicit special
case of zip files). This is likely to be a fairly long posting, but
I'd like to try and c
56 matches
Mail list logo
