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:
>>
"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 th
2010/9/18 "Martin v. Löwis" :
> 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, but it's just as
On 18/09/2010 18:27, Nick Coghlan wrote:
On Sat, Sep 18, 2010 at 10:24 PM, Michael Foord
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
provid
On Sat, Sep 18, 2010 at 10:24 PM, Michael Foord
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 don't
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, people
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 da
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
ques
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
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
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 t
2010/9/18 "Martin v. Löwis" :
>> 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 depe
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 have
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
On Sat, Sep 18, 2010 at 4:01 PM, Michael Foord
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 stands though. The depend
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 and
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 HTML,
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 av
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 to
On Sat, Sep 18, 2010 at 7:50 PM, Michael Foord
wrote:
> On 18/09/2010 11:48, David Cournapeau wrote:
>>
>> On Sat, Sep 18, 2010 at 7:39 PM, Michael Foord
>> 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
On 18/09/2010 11:48, David Cournapeau wrote:
On Sat, Sep 18, 2010 at 7:39 PM, Michael Foord
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?
Tha
On Sat, Sep 18, 2010 at 7:39 PM, Michael Foord
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 take for all packag
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
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 i
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 ill-def
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 s
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
On Fri, Sep 17, 2010 at 10:02 PM, Jannis Leidel 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 egg_info d
28 matches
Mail list logo
