Hello here too :-)
On 10/12/11 11:31 PM, Jon Stahl wrote:
On Tue, Oct 11, 2011 at 8:00 AM, Alex Clark<[email protected]> wrote:
Hi,
On 10/11/11 12:59 AM, Dylan Jay wrote:
Hi,
There was a previous thread where this was brought up but nothing
resolved.
Plugins these days tend to get released on plone.org OR pypi but not
always both.
This is confusing for inexperienced intergrators or end customers.
For instance looking at plone.org you'd think Products.PloneGlossary is
unmaintained
http://plone.org/products/ploneglossary
but if you look at pypi you realise it is maintained.
http://pypi.python.org/pypi/Products.PloneGlossary/1.5.0b3#b3-2011-07-15
There were some clever suggestions about how to fix this but none seems
particularly easy.
For instance make PSC mirror all the releases for software it manages
from pypi.
Anyone got a bright idea on how to fix this?
Easy fixes
==========
The easiest fix would be to disable/abandon plone.org/products, but I don't
think anyone wants to do that yet (including me).
The next easiest "fix" (which isn't really a fix) is to promote
dual-releases via mkrelease, releaser, etc.
Hard fixes
==========
As you mention, we could build some clever system to list PyPI entries on
plone.org. But I think the new http://opencomparison.org/ stuff tackles some
of this and I don't want to duplicate that effort.
But the hardest fix involves just being able to do *anything* on plone.org
right now. There are many ideas/tasks floating around; and I know the board
is actively seeking resolution(s); I hope some of these will materialize
between now and the end of the year:
* Upgrade plone.org to 4.2.x
* Create a plonetheme.ploneorg package to hold the "new" theme, and factor
it out of Products.PloneOrg
* Make releases for all dependencies and update the buildout, most of this
has been done and is reflected in
https://github.com/plone/Products.PloneOrg/tree/4.1-compat
I think Alex pretty much hits the nail on the head here. In the short
term, as I see it, the only sensible solution is to actively promote
dual-releasing. It is really really easy, I just think awareness is
not as high as it needs to be. That is probably best changed by
one-on-one contact with product authors (and maybe a simple FAQ that
Alex (?) could write up on how to do it, so that anybody can easily
nag someone about this.) We can't force people to do it, but we sure
as heck can make it clear what "community best practice" is.
True. I think community best practice is currently dual release until
such time as we conquer the next milestone, whatever that may be. Point
of fact, I doubt anyone actually uses the releases we host via the
plone.org PSC. By default, PyPI is used. You have to go out of your way
to specify you want to download a package from dist.plone.org and I
suspect almost no one does this.
So, dual release accomplishes two important things:
- package upload to PyPI (where people's buildouts can download it)
- content upload to PSC (where people browsing our site can find out
about it)
The fact the packages are hosted on dist.plone.org in addition to PyPI
is almost irrelevant (as far as the status quo is concerned at least; we
could change this by promoting our dist.plone.org index, but I'm not
sure that makes any sense.)
Alex
In the longer term, I do think we want to seriously consider shifting
Plone.org to be more of a selective Pypi scraper. We'd have to think
about how to best include the ultra-important Plone version
compatibility metadata, but I assume that with so many smart folks
running around, that is solveable.
$0.02,
jon
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers
