I am in full agreement with Tarek here. At ActiveState, we maintain
our own index that differs from PyPI in two ways (among others):
I think you are saying something very different from what Tarek
says. IIUC, you are saying that egg-info is ill-defined and may
cause subtle problems. So you are
On 18/09/2010 08:52, Martin v. Löwis wrote:
I am in full agreement with Tarek here. At ActiveState, we maintain
our own index that differs from PyPI in two ways (among others):
I think you are saying something very different from what Tarek
says. IIUC, you are saying that egg-info is
With the distutils2 work very close to landing in the standard library,
providing infrastructure that will cause tools to *depend* on the old
formats is a very bad idea.
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that
On 18/09/2010 11:03, Martin v. Löwis wrote:
With the distutils2 work very close to landing in the standard library,
providing infrastructure that will cause tools to *depend* on the old
formats is a very bad idea.
I think you are misunderstanding. The infrastructure will *not* depend
on the
On Sat, Sep 18, 2010 at 7:39 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 18/09/2010 11:03, Martin v. Löwis wrote:
That's really sad. So people will have to wait a few years to efficiently
implement tools that they could implement today.
Why a few years?
That's the time it will
On 18/09/2010 11:48, David Cournapeau wrote:
On Sat, Sep 18, 2010 at 7:39 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 18/09/2010 11:03, Martin v. Löwis wrote:
That's really sad. So people will have to wait a few years to efficiently
implement tools that they could implement
On Sat, Sep 18, 2010 at 7:50 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 18/09/2010 11:48, David Cournapeau wrote:
On Sat, Sep 18, 2010 at 7:39 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 18/09/2010 11:03, Martin v. Löwis wrote:
That's really sad. So people will have
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that information will
provide it, packages that don't will not. The infrastructure is entirely
agnostic on whether the data is available or not. In particular, it will
not try
On 18/09/2010 12:25, Martin v. Löwis wrote:
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that information will
provide it, packages that don't will not. The infrastructure is
entirely
agnostic on whether the data is
No. See above comment. If exposing this information has no value then
don't do it. If it does have value, then we are blessing it - and
therefore blessing it *over* other formats.
No: not *over*. Only over formats that don't get exposed. However,
the PEP 345 data are *already* exposed, via
Ok, I'm sorry - PEP 345 information is available via the PyPI API. (So
exposing egg_info would not be promoting it *over* distutils2 but it
would still be promoting and blessing it).
Tarek's main point still stands though. The dependency information in
the egg_info is tied to the platform
On Sat, Sep 18, 2010 at 4:01 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Ok, I'm sorry - PEP 345 information is available via the PyPI API. (So
exposing egg_info would not be promoting it *over* distutils2 but it would
still be promoting and blessing it).
Tarek's main point still
So if the use case is to provide dependency information exposing
egg_info is not the right way to do it - and tools that use it will be
using potentially (and frequently) inaccurate information. I stand by
the point that once we start providing this information tools will start
using it, and they
So, I don't understand what is the benefit here, since a serious
installer will re-run egg_info every time.
I think the main applications that people are after are not builds.
They want the dependency information without downloading the packages,
and dependency information for packages they
2010/9/18 Martin v. Löwis mar...@v.loewis.de:
So, I don't understand what is the benefit here, since a serious
installer will re-run egg_info every time.
I think the main applications that people are after are not builds.
They want the dependency information without downloading the packages,
At 05:19 PM 9/18/2010 +0200, Martin v. Löwis wrote:
In the specific case of tl.eggdeps, the dependency information is only
used to create printable graphs. If this turns out to be slightly
incorrect, people would notice if they try to use the packages in
question.
By the way, just providing
Tarek Ziadé writes:
Good enough metadata sounds completely wrong to me.
I hate to break it to you, but experience shows that the XEmacs
package system, whose dependency tracking is in theory a pile of
braindamaged rubbish, an abomination in the sight of She Who Created
The World With 4-Space
So you are fine with publishing slightly incorrect metadata at PyPI
? I am not.
I really have no intuition for in how many cases the data will be
incorrect. However, if users find that the data is incorrect for
specific package, they ought to complain to the maintainer.
I don't understand
Am 18.09.10 17:49, schrieb P.J. Eby:
At 05:19 PM 9/18/2010 +0200, Martin v. Löwis wrote:
In the specific case of tl.eggdeps, the dependency information is only
used to create printable graphs. If this turns out to be slightly
incorrect, people would notice if they try to use the packages in
Stephen J. Turnbull wrote:
In the meantime, it's better to let people using a competing standard
(even if it's neither very good nor a real standard) do their thing
until they see the light.
It's not even about the people who consume egg-info data seeing the light,
it's about PEP-345 data
At 06:06 PM 9/18/2010 +0200, Martin v. Löwis wrote:
Am 18.09.10 17:49, schrieb P.J. Eby:
At 05:19 PM 9/18/2010 +0200, Martin v. Löwis wrote:
In the specific case of tl.eggdeps, the dependency information is only
used to create printable graphs. If this turns out to be slightly
incorrect,
On Sat, Sep 18, 2010 at 10:24 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 18/09/2010 12:25, Martin v. Löwis wrote:
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that information will
provide it, packages that
On 18/09/2010 18:27, Nick Coghlan wrote:
On Sat, Sep 18, 2010 at 10:24 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 18/09/2010 12:25, Martin v. Löwis wrote:
I think you are misunderstanding. The infrastructure will *not* depend
on the old formats. Instead, packaging that have that
2010/9/18 Martin v. Löwis mar...@v.loewis.de:
Any other opinions?
-1 from me as well; I see no reason to encourage use of bad metadata,
given mechanisms to get correct metadata exist (running setup.py
egg_info, as others have pointed out). I understand there are
perceived uses for such data,
Martin v. Löwis wrote:
So you are fine with publishing slightly incorrect metadata at PyPI
? I am not.
I really have no intuition for in how many cases the data will be
incorrect. However, if users find that the data is incorrect for
specific package, they ought to complain to the
On 2010-09-18, at 2:29 AM, Thomas Lotze wrote:
I'd like to expand [tl.eggdeps]
to analyse dependencies between any packages on PyPI but I can't
as long as dependency information is not available without actually
installing things. [...]
On 2010-09-18, at 2:29 AM, Thomas Lotze wrote:
I am
On Fri, Sep 17, 2010 at 10:02 PM, Jannis Leidel jan...@leidel.info wrote:
On 17.09.2010, at 20:43, Martin v. Löwis wrote:
Here at the DZUG conference, we are planning to integrate explicit access to
setuptools metadata to the package index.
The current idea is to store the contents of the
On 2010-09-17, at 4:04 PM, Tarek Ziadé wrote:
I am not even understanding what's the benefit of doing this since an
egg_info directory is obtained at *build* time and can differ from a
machine to another, so it seems pretty useless for me to publish this.
I am in full agreement with Tarek
28 matches
Mail list logo
