#152 Provide access to hidden versions

open
nobody
None
5
2011-12-08
2011-12-08
Dieter Maurer
No

By default, the index hides non current versions -- which probably is a good feature. However, often versions are targeted towards a larger framework and the used version needs to be synchronized with the framework version. In those cases, it would be helpfull to have access to the list of registered versions. I therefore propose some form of "button" on the package detail page that leads to a page with all registered versions for the package.

Discussion

  • Can you please elaborate on that need? The hidden versions are readily accessible for downloading and also for browsing, and the APIs allow to retrieve them. Why is it that you need a button?

     
  • Dieter Maurer
    Dieter Maurer
    2011-12-09

    >>Comment By: Martin v. Löwis (loewis)
    >Date: 2011-12-08 08:58
    >
    >Message:
    >Can you please elaborate on that need? The hidden versions are readily
    >accessible for downloading and also for browsing, and the APIs allow to
    >retrieve them. Why is it that you need a button?

    I suggested this button because I do not know (and did not find) how hidden versions are available for "browsing". The button would make available this functionality. If it is already there, then the better. In this case, maybe, it should be more exposed (to better find it).

     
  • I still don't understand. What's your use case? Please make a specific example: what specific package did you care about, and what specific action did you want to perform (and why)?

     
  • Dieter Maurer
    Dieter Maurer
    2011-12-09

    > What's your use case? Please make a specific
    > example: what specific package did you care about, and what specific action
    > did you want to perform (and why)?

    What triggered my request: I had a need to install "Products.PloneBoard" into a Plone 3.3 installation. "Products.PloneBoard" directly or indirectly depends on half a dozen other packages. While I fixed the version of "PloneBoard" to be compatible with Plone 3.3, the versions of dependent packages chosen by buildout where inadequate for Plone 3.3. I must pin versions for those packages explicitely. To this end, I must learn which versions are available. Most authors bump the version number significantly when they start to depend on a major new framework version (in this case Plone); other authors (like me) put compatibility information into the title. Thus, seeing a list of available versions with the corresponding titles significantly helps to pin the versions that have a chance to work with Plone 3.3.

    This problem is more general (than Plone): it has a chance to occur whenever you want to install a package dependent on various other packages into a complex framework also dependent on many packages. All these packages must fit togehter. To explore which versions you should try, you must at least know which versions are available.

     
  • To see all versions of PloneBoard, go to

    http://pypi.python.org/pypi/?:action=index&name=Products.Ploneboard&_pypi_hidden=1

    Or, in a programmatic way, try

    py> s=xmlrpclib.Server("http://pypi.python.org/pypi")
    py> s.package_releases('Products.Ploneboard', True)
    ['3.1', '3.0', '2.2', '2.1b2', '2.0rc1', '2.0b2', '2.0b1', '2.0.1', '2.0']

    py> for r in s.package_releases('Products.Ploneboard', True):
    ... print r, s.release_data('Products.Ploneboard', r)['summary']
    ...
    3.1 A discussion board for Plone.
    3.0 A discussion board for Plone.
    2.2 A discussion board for Plone.
    2.1b2 A discussion board for Plone.
    2.0rc1 A discussion board for Plone.
    2.0b2 A discussion board for Plone.
    2.0b1 A discussion board for Plone.
    2.0.1 A discussion board for Plone.
    2.0 A discussion board for Plone.

    Yet alternatively, go to

    http://pypi.python.org/simple/Products.Ploneboard/

    The latter two are documented; the first one is probably what would meet your immediate request closest.

    I'm skeptical that adding an "unhide" button is a good idea: people have hidden these releases for a reason (so that end users won't find them anymore, but only setuptools still finds them). Giving an easy access to hidden releases would defeat that purpose.