|
List Info
Thread: Re: How to get a list of package releases
|
|
| Re: How to get a list of package
releases |
|
2007-01-22 23:15:02 |
|
At 03:54 AM 1/23/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
>On 1/22/07, Phillip J. Eby telecommunity.com> wrote:
> > At 05:15 PM 1/22/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
> > >Currently we have a lot more logic in the client (easy_install) than
> > >in the server (PyPI). So now we have this strange situation when an
> > >installation client knows more about a package than the packages
> > >server. Shouldn't we constantly move toward removing magic from
> > >setuptools and porting important bits to PyPI?
> >
> > I dunno. What actual problem are you trying to solve, or what use case
> > are you trying to support?
>
>Cleaner architecture probably.
To accomplish what goals? "Cleaner" can't be defined without reference to
some goal, like reduction of bugs, ease of extension/change, etc.
> Or is sourceforge magic going to stay?
>I always thought sourceforge support was temporary, just to ease
>migration toward setuptools.
The SourceForge magic is essentially gone as of 0.6c5; SourceForge fixed
their system so that neither screenscraping nor SF URL recognition is required.
> > For example, why do you want to know what versions are available *in an
> > automated way*?
>
>Why we write programs at all? To automate things we don't want to
>repeatedly do ourselves. If setuptools is so good at finding available
>versions of a package, why should we force user to find these
>information themself?
I still don't understand you. What will they be using that information *for*?
> If we can take out pain from PyPI user
>experience, we should do it.
You haven't shown that the absence of this information is causing anybody
any pain, beause I don't know what you are expecting anybody to *do* with
this information. I can't say I have ever needed this; I just install the
latest version, or I specify a specific version.
I can't recall ever wanting to find out "what versions are available", in
other words. So I still don't know what problem you're trying to solve.
>Maybe you ask about why on earth someone needs a list of releases?
Yes.
>Well, maybe someone finds a bug in current release and want to try
>earlier version. If the current release is 0.8 how user will know what
>was the previous? Was it 0.7? 0.7.5? Maybe 0.8rc3?
"easy_install 'thepackage<0.8'" will find it and install it.
>Of course there are more use cases.
Such as?
>I don't really understand why this have to be
>explained - probably each package index out there (freshmeat, CPAN,
>rubyforge, sourceforge, berlios) have a list of releases available.
So does PyPI - you just have to manually follow the links right now, unless
you want it in *machine-readable* form (e.g. so you can then display it to
the user).
So, the use case of "I just want to know what releases are available" is
handled already, if you assume a human user. It may not be *convenient*,
but it is clearly *possible*.
>"We don't need this because nobody asked for it" is a really bad excuse
You seem to be under the impression that I said the feature isn't
needed. In fact, I am *still* merely trying to find out what problem you
are trying to solve!
This is an essential first step before trying to design a solution, but you
appear to be under the impression that people should somehow telepathically
know what problem you are trying to solve, perhaps by reverse-engineering
your proposed solution (which is underspecified in any event).
I think perhaps that you are also under the mistaken impression that I have
anything to do with how PyPI is maintained, developed, or operated; I only
maintain setuptools, so anything you want done server-side is another
issue. setuptools uses PyPI, but the two are conceptually distinct (unlike
say, CPAN, where the client and server are more-or-less considered parts of
one whole).
>Having said that I'll try to propose few more improvements in oncoming
>weeks, that will make PyPI experience better, I hope. If you have any
>suggestions on what is lacking, I will love to hear them.
Certainly there are UI (and other) improvements to PyPI that I would like
to see, and I've proposed/requested many of them on this list more than
once in the past. However, in the absence of volunteers to *implement*
those requested improvements, there is unlikely to be any change in the
status quo.
_______________________________________________
Catalog-sig mailing list
Catalog-sig python.org
http://mail.python.org/mailman/listinfo/catalog-sig
|
| Re: How to get a list of package
releases |
|
2007-01-27 11:40:45 |
At 06:07 PM 1/27/2007 +0100,
=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
>On 1/23/07, Phillip J. Eby <pjetelecommunity.com>
wrote:
> > At 03:54 AM 1/23/2007 +0100,
=?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
> > > Or is sourceforge magic going to stay?
> > >I always thought sourceforge support was
temporary, just to ease
> > >migration toward setuptools.
> >
> > The SourceForge magic is essentially gone as of
0.6c5; SourceForge fixed
> > their system so that neither screenscraping nor SF
URL recognition is
> > required.
>
>Still sourceforge is treated in a special way.
Uh, no, it isn't.
> Users of other systems
>have to manually put their links/files on PyPI.
So do users of SourceForge.
>Is this special
>support going to stay? And is it working, for example,
with
>BerliOS-hosted projects?
If your "Home Page" or "Download URL" on
PyPI is a page that contains
direct download links, easy_install will recognize them.
This means that
if your Download URL is a SF files page, the links will get
recognized. If
BerliOS or whatever has similar pages, and somebody links
the right page
from their download URL, then it should also work.
> > >Well, maybe someone finds a bug in current
release and want to try
> > >earlier version. If the current release is 0.8
how user will know what
> > >was the previous? Was it 0.7? 0.7.5? Maybe
0.8rc3?
> >
> > "easy_install 'thepackage<0.8'" will
find it and install it.
>
>What if user doesn't have easy_install installed when he
is looking
>for an answer? Maybe he knows where in the code the
problem lies, so
>he want to check earlier versions' code without
installing? Maybe he
>want to skim through changelog?
And how is that a requirement for an automated list of
versions? All of
that is stuff that requires manual searching anyway; the
data that
easy_install gathers isn't going to help you there.
>PyPI should be usable on itself, it's a web interface
after all.
Yep, and it works just fine. See, it has a "home
page" link where people
can go to the project's actual home page to find things out
about it.
>What links? Where are the links for all published
releases of a given
>package? Did I miss something?
PyPI shows the packages the owner has chosen to show. If
the owner doesn't
show old releases, that's his or her choice.
> > >"We don't need this because nobody asked
for it" is a really bad excuse
> >
> > You seem to be under the impression that I said
the feature isn't
> > needed. In fact, I am *still* merely trying to
find out what problem you
> > are trying to solve!
>
>Again: "PyPI can't show a list of package
releases" (isn't this in a
>message subject?).
I still fail to see why this is a problem. It's not PyPI's
job to show
releases a package owner has chosen to hide.
However, you could argue perhaps that the mere act of
creating a new
release shouldn't cause older releases to become hidden --
in other words,
showing releases by default instead of hiding them. You
could also argue
for changelog-like features, or other features.
What is still NOT clear -- because you still haven't
explained it -- is why
this information needs to be available to automated tools,
as opposed to
simply being available to humans through the web interface.
None of the
use cases you've presented seem to call for an automated
tool.
_______________________________________________
Catalog-sig mailing list
Catalog-sigpython.org
h
ttp://mail.python.org/mailman/listinfo/catalog-sig
|
|
[1-2]
|
|