If you don't change this manually, it'll display the latest and hide
the others, everytime
you register and upload a release at PyPI. As, most projects do.
Distribute was just an example.
Alternatively, you can also uncheck the auto-hide box on the package,
I would agree that auto-hide is
On Wed, Dec 2, 2009 at 2:21 PM, Martin v. Löwis mar...@v.loewis.de wrote:
I'd like to see how the PyPI UI works out. I can also imagine a more
extensible setup, like:
Project-URLs: documentation=http://myproject.org/docs/
repository=http://myproject.org/svn/
mailing
I think it would be generally useful if old releases included a
warning in the PyPI interface (some prominent box that said This is
an old release! The newest release is a href=X.YX.Y/a).
They do already.
It's
actually pretty easy to get unintentionally to an old release via
search
Hello
As suggested here, then discussed at Distutils-SIG, I would like to
propose the addition of two more fields for the
upcoming Metadata 1.2 (PEP 345) that could be used at PyPI on projects pages.
Repository-Browse-URL
A string containing the URL for the package's browsable
repository.
Tarek Ziadé wrote:
Hello
As suggested here, then discussed at Distutils-SIG, I would like to
propose the addition of two more fields for the
upcoming Metadata 1.2 (PEP 345) that could be used at PyPI on projects pages.
Repository-Browse-URL
A string containing the URL for the package's
Tarek Ziadé wrote:
Hello
As suggested here, then discussed at Distutils-SIG, I would like to
propose the addition of two more fields for the
upcoming Metadata 1.2 (PEP 345) that could be used at PyPI on projects pages.
Repository-Browse-URL
A string containing the URL for the
On Wed, Dec 2, 2009 at 11:28 AM, Chris Withers ch...@simplistix.co.uk wrote:
The only controversial ones were Change-Log-URL and, at a push,
Documentation-URL (although it was only you who even queried that ;-), so
why have Repository-URL and Mailing-List-URL been abandoned?
I didn't notice
On 2009-12-02 11:43 AM, M.-A. Lemburg wrote:
While more structured meta-data is generally better than less,
I wonder why we have to add URLs for all these things.
The home page of a project will usually provide the URLs
in some form already and if there is no home page, the
long description
I'd like to see how the PyPI UI works out. I can also imagine a more
extensible setup, like:
Project-URLs: documentation=http://myproject.org/docs/
repository=http://myproject.org/svn/
mailing list=http://googlegroups.com/groups/myproject
I think this also points to an important
On Wed, Dec 2, 2009 at 9:21 PM, Martin v. Löwis mar...@v.loewis.de wrote:
I'd like to see how the PyPI UI works out. I can also imagine a more
extensible setup, like:
Project-URLs: documentation=http://myproject.org/docs/
repository=http://myproject.org/svn/
mailing
But the project always wants to display the newest urls.
Not at all. For some projects, it's more important to be conscious about
documentation versions than for others. For example
http://www.postgresql.org/docs/
asks you to make an explicit choice of version, and the URLs reflect
that.
Tarek Ziadé wrote:
2009/12/2 Martin v. Löwis mar...@v.loewis.de:
[..]
For Python, it somewhat unfortunate that there is a tradition of
newest documentation. When the documentation format changed, many
URLs broke - something that would not have happened when all URLs
had been versioned.
Robert Kern wrote:
On 2009-12-02 11:43 AM, M.-A. Lemburg wrote:
While more structured meta-data is generally better than less,
I wonder why we have to add URLs for all these things.
The home page of a project will usually provide the URLs
in some form already and if there is no home page, the
2009/12/3 Martin v. Löwis mar...@v.loewis.de:
On the long_description front, the default behavior is to display the
latest one
That's not true. If there are multiple visible releases, no release
is singled out.
What ? the statement the default behavior is to display the latest
one *is* true
14 matches
Mail list logo
