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:
>>
Am 18.09.2010 15:27, schrieb Steve Holden:
> On 9/18/2010 9:21 AM, "Martin v. Löwis" wrote:
>> IT WILL BE NOT IN PREFERENCE TO DISTUTILS2.
>
> No need to shout.
I really felt that this otherwise wouldn't be heard - I tried
to say it a number of times before, and it was ignored.
Regards,
Martin
_
"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
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
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
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 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 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
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 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
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
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
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
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,
Could a few of those "people" please provide us with concrete examples (in
code) that'd make use of this data?
Unfortunately, I personally don't recall all the people that had been
requesting something like this over the years. Currently, Thomas Lotze
and Jim Fulton have been supporting this
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
Hi there,
I'm going to add my own 2 cents to the discussion as I'm involved in the
matter here at the DZUG conference.
Tarek Ziadé wrote:
> Now you want to publish another metadata format at PyPI ? If PyPI takes
> that direction and adopts, promotes and publishes a standard that is not
> the one
On 18.09.2010, at 09:44, Martin v. Löwis wrote:
>> I'm confused, wouldn't that basically be a slap in the face for the
>> people having worked on PEP345 and distutils2, especially during the
>> Summer of Code?
>
> How so? That work is still useful.
Well, useful like a toothless tiger.
> Also,
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 September 2010 08:44, "Martin v. Löwis" wrote:
> [snip...]
>
>> Also, and I understand enthusiasm tends to build up during
>> conferences, but wouldn't supporting setuptools' egg-info directory
>> again be a step backwards after all those months of discussion about
>> the direction of Pytho
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
I'm confused, wouldn't that basically be a slap in the face for the
people having worked on PEP345 and distutils2, especially during the
Summer of Code?
How so? That work is still useful.
Also, and I understand enthusiasm tends to build up during
conferences, but wouldn't supporting setuptools
FYI, egg-info directories can store arbitrary data (see e.g. the
EggTranslations package, which uses it for localization resources), so
you may want to impose some restrictions on *which* metadata files to
include.
You mean, so that it doesn't include malware, porn, or other spam?
That would be
Since egg_info results may vary depending on the platform used to built
it, how do you plan to do this so people can use these files ?
See below for how exactly the data is provided (in particular, the
oldest egg is used, unless the user explicitly posts other data).
Whether or not the data i
32 matches
Mail list logo
