On Thu, Jun 17, 2010 at 16:59, Tres Seaver tsea...@palladion.com wrote:
All of which make it impossible to reliably and repeatably deploy
arbitrary software configurations (directly) from PyPI. Managing your
own project-specific index is the only real solution.
When I provide buildout
On Thu, Jun 17, 2010 at 5:36 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Now, please tell me what you would do if sourceforge changes its url and
returns a
404 on the old download page. Would you update all release informations?
Well, at this point if sourceforge 404'ed on an old download
On Fri, Jun 18, 2010 at 11:47 AM, Mark Ramm m...@geek.net wrote:
On Thu, Jun 17, 2010 at 5:41 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
It does? I thought PyPI kept everything around (but hidden) unless the
author went in and manually deleted old stuff. You just need to go to a
deep
At 01:07 AM 6/19/2010 +0200, Martin v. Löwis wrote:
Am 18.06.2010 18:47, schrieb Mark Ramm:
On Thu, Jun 17, 2010 at 5:41 PM, Martin v.
Löwismar...@v.loewis.de wrote:
It does? I thought PyPI kept everything around (but hidden) unless the
author went in and manually deleted old stuff. You
Am 19.06.2010 01:57, schrieb P.J. Eby:
At 01:07 AM 6/19/2010 +0200, Martin v. Löwis wrote:
Am 18.06.2010 18:47, schrieb Mark Ramm:
On Thu, Jun 17, 2010 at 5:41 PM, Martin v.
Löwismar...@v.loewis.de wrote:
It does? I thought PyPI kept everything around (but hidden) unless the
author went in
On 2010-06-17 06:22:32 +0200, Andreas Jung li...@zopyx.com said:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I propose a policy change for packages registered with PyPI:
- packages registered on PyPI have at least one release
- one release of registered package on PyPI _must_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
I propose a policy change for packages registered with PyPI:
- packages registered on PyPI have at least one release
- one release of registered package on PyPI _must_ contain
a valid source code distribution
Andreas Jung wrote:
Hi there,
I propose a policy change for packages registered with PyPI:
- packages registered on PyPI have at least one release
I'm not sure what you mean with release. Every package on
PyPI is a release, since it comes with a version number.
- one release of
Martin v. Löwis wrote:
For such packages: send out an email to the package maintainer informing
him about the problem and instructing him to fix the problem within N
days.
After N days: recheck the package state and unregister the package if
necessary.
Or perhaps a less rude approach:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
Andreas Jung wrote:
Hi there,
I propose a policy change for packages registered with PyPI:
- packages registered on PyPI have at least one release
I'm not sure what you mean with release. Every package on
PyPI is a
Andreas Jung wrote:
M.-A. Lemburg wrote:
Andreas Jung wrote:
Hi there,
I propose a policy change for packages registered with PyPI:
- packages registered on PyPI have at least one release
I'm not sure what you mean with release. Every package on
PyPI is a release, since it comes with a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
I guess it's better to tell the package authors about your
use of their packages and offer them help in hosting their
packages on more reliable infrastructures.
If that doesn't solve your problem, it's likely better
Andreas Jung wrote:
M.-A. Lemburg wrote:
I guess it's better to tell the package authors about your
use of their packages and offer them help in hosting their
packages on more reliable infrastructures.
If that doesn't solve your problem, it's likely better
to either setup your
Hi,
On 2010-06-17 11:51:13 +0200, M.-A. Lemburg said:
Back to your proposal: In your particular case, I don't see
how the proposal would have helped you - under the proposal,
the package would have been removed from the PyPI index,
so either way, there would have been no working automatic
Kai Diefenbach wrote:
Hi,
On 2010-06-17 11:51:13 +0200, M.-A. Lemburg said:
Back to your proposal: In your particular case, I don't see
how the proposal would have helped you - under the proposal,
the package would have been removed from the PyPI index,
so either way, there would have
On Thu, Jun 17, 2010 at 12:47, M.-A. Lemburg m...@egenix.com wrote:
Kai Diefenbach wrote:
Hi,
On 2010-06-17 11:51:13 +0200, M.-A. Lemburg said:
Back to your proposal: In your particular case, I don't see
how the proposal would have helped you - under the proposal,
the package would
Patrick Gerken wrote:
On Thu, Jun 17, 2010 at 12:47, M.-A. Lemburg m...@egenix.com wrote:
Kai Diefenbach wrote:
Hi,
On 2010-06-17 11:51:13 +0200, M.-A. Lemburg said:
Back to your proposal: In your particular case, I don't see
how the proposal would have helped you - under the proposal,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
What I'm saying is that it's better to contact the package
authors whose entries cause problems than to force some
policy on all PyPI package entries which carelessly puts
packages that are not hosted on PyPI into the same
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
And lastly, uploading packages to PyPI (still) has a serious
problem: setuptools doesn't know the distinction between
UCS2 and UCS4, so uploading eggs for Unix platforms doesn't
work out in practice. setuptools also doesn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Note however that Andreas' proposal was to require that 'sdists' be
uploaded. I personally won't use binary-only packages, but it has
historically been true that PyPI was intended to support them, as well
as to support
On Thu, Jun 17, 2010 at 7:40 AM, M.-A. Lemburg m...@egenix.com wrote:
http://pypi.python.org/simple/zc.buildout/
BTW: what are all those bug links doing on the zc.buildout index page ?
PyPI scrapes all the links from the long description; for many projects
that includes a change log with links
Andreas Jung wrote:
Tres Seaver wrote:
Note however that Andreas' proposal was to require that 'sdists' be
uploaded. I personally won't use binary-only packages, but it has
historically been true that PyPI was intended to support them, as well
as to support registration of packages hosted
On Thu, Jun 17, 2010 at 13:40, M.-A. Lemburg m...@egenix.com wrote:
Patrick Gerken wrote:
As a plone user who uses zc.buildout I very much prefer reliable
downloads.
Its not fun
to search for the reason a supposedly repeatable buildout suddenly fails
because
a company decided to
On Thu, 17 Jun 2010 09:20:55 pm Patrick Gerken wrote:
Not putting the source release on pypi is just one indicator of
crappy software.
Yeah, like that infamous example of crappy software, Numpy.
http://pypi.python.org/pypi/numpy/1.4.1
--
Steven D'Aprano
On Thu, Jun 17, 2010 at 14:55, Steven D'Aprano st...@pearwood.info wrote:
On Thu, 17 Jun 2010 09:20:55 pm Patrick Gerken wrote:
Not putting the source release on pypi is just one indicator of
crappy software.
Yeah, like that infamous example of crappy software, Numpy.
Benji York wrote:
On Thu, Jun 17, 2010 at 7:40 AM, M.-A. Lemburg m...@egenix.com wrote:
http://pypi.python.org/simple/zc.buildout/
BTW: what are all those bug links doing on the zc.buildout index page ?
PyPI scrapes all the links from the long description; for many projects
that includes a
Andreas Jung li...@zopyx.com writes:
M.-A. Lemburg wrote:
You'd outrule commercial packages that don't come with a source
distribution. PyPI is for everyone, not only for open source
packages.
Commercial package are a special case - I agree. The majority of all
PyPI are non-commercial.
This would also impact projects like turbogears (perhaps we're the
only one, I don't know) that point to our own pypi compatable index
with the download URL. We do this because then we can fix things
like packages with no windows eggs, packages that are broken on PyPi
or whatever. And to help
On Thu, 17 Jun 2010 04:11:19 pm Christian Zagrodnick wrote:
On 2010-06-17 06:22:32 +0200, Andreas Jung li...@zopyx.com said:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I propose a policy change for packages registered with PyPI:
- packages registered on PyPI have at
Andreas Jung-5 wrote:
Hi there,
I propose a policy change for packages registered with PyPI:
- packages registered on PyPI have at least one release
- one release of registered package on PyPI _must_ contain
a valid source code distribution (sdist)
- packages registered on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ronald Oussoren wrote:
On 17 Jun, 2010, at 13:20, Patrick Gerken wrote:
Please have a look at the package in question. The only problem
with it is that the download URL registered on PyPI no longer works.
It redirects to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
Andreas Jung wrote:
Tres Seaver wrote:
Note however that Andreas' proposal was to require that 'sdists' be
uploaded. I personally won't use binary-only packages, but it has
historically been true that PyPI was intended to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steven D'Aprano wrote:
On Thu, 17 Jun 2010 09:20:55 pm Patrick Gerken wrote:
Not putting the source release on pypi is just one indicator of
crappy software.
Yeah, like that infamous example of crappy software, Numpy.
Andreas Jung wrote:
M.-A. Lemburg wrote:
Andreas Jung wrote:
Tres Seaver wrote:
Note however that Andreas' proposal was to require that 'sdists' be
uploaded. I personally won't use binary-only packages, but it has
historically been true that PyPI was intended to support them, as well
as
How do you ensure the availability of the index and the packages at
any time?
By keeping our server up, and not depending on pypi. If our server
goes down, packages will become unavailable, but if you want a mirror
for a particular revision of tg and all it's dependencies you can just
grab a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Ramm wrote:
How do you ensure the availability of the index and the packages at
any time?
By keeping our server up, and not depending on pypi. If our server
goes down, packages will become unavailable, but if you want a mirror
for a
On Thu, Jun 17, 2010 at 1:15 PM, Mark Ramm m...@geek.net wrote:
Would you use PyPI as download server or as primary location if it would
be more reliable or having a usuable mirroring infrastructure?
No. Because it would still drop old packages, allow people to upload
new packages and
On Thu, Jun 17, 2010 at 12:40 PM, Andreas Jung li...@zopyx.com wrote:
Once again: I am talking about the majority of packages that are neither
commercial nor shipping without the Python source code.
This seems to say either that you don't care about the supposed
minority of packages that are
Previously in this thread, there have been several plausible
suggestions for modifying (improving?) zc.buildout to cope with the
issues you've identified. Have you relayed these suggestions to the
zc.buildout developers and administrators? Do you know for a fact
that zc.buildout can't be
Am 17.06.2010 15:16, schrieb M.-A. Lemburg:
Benji York wrote:
On Thu, Jun 17, 2010 at 7:40 AM, M.-A. Lemburgm...@egenix.com wrote:
http://pypi.python.org/simple/zc.buildout/
BTW: what are all those bug links doing on the zc.buildout index page ?
PyPI scrapes all the links from the long
Note that even a requirement to upload a package to PyPI won't reliably
solve Andreas' problem, the package owner could remove a release or even
the entire package.
Released is released. There are only very few cases where one should be
allowed to remove packages (e.g. containing viruses,
Now, please tell me what you would do if sourceforge changes its url and
returns a
404 on the old download page. Would you update all release informations?
If not, the next time I run a buildout where the configuration requires
numpy in an old version
and the download link is broken, my buildout
It does? I thought PyPI kept everything around (but hidden) unless the
author went in and manually deleted old stuff. You just need to go to a
deep link, e.g., http://pypi.python.org/pypi/SomePackage/0.1
Sure, but owners *do* manually delete old stuff.
Regards,
Martin
Didn't Setuptools/easy_install began this policy of following the
download_url from PyPI's early days when it wasn't even possible to
upload to PyPI (or at least during the transition when a majority of
packages only provided download_urls).
Not sure whether this was rhetoric: yes, that's how
On Jun 17, 2010, at 18:53, Andreas Jung li...@zopyx.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ronald Oussoren wrote:
On 17 Jun, 2010, at 13:20, Patrick Gerken wrote:
Please have a look at the package in question. The only problem
with it is that the download
Steven D'Aprano st...@pearwood.info writes:
On Thu, 17 Jun 2010 04:11:19 pm Christian Zagrodnick wrote:
On 2010-06-17 06:22:32 +0200, Andreas Jung li...@zopyx.com said:
- one release of registered package on PyPI _must_ contain
a valid source code distribution (sdist)
-1000
I'm looking at PyPi as infrastructure and upstream source for Linux
distributions.
* Renaming packages
I would strongly say NO to this one. Once you make a release, don't
change it. If mistake in metadata/packaging was done, make new release
like 1.0 - 1.0-r1
* Source code requirement
This one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
In theory yes, in real life no - I approached several package
maintainers in the past due to several reasons..some agree with the
complaints, others just don't care. Some consider PyPI as their own
private repository with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I retract this proposal and accepting the fact that obviously nobody
outside the Zope/Plone world is really interested in bringing PyPI
forward and putting the freedom to register and upload packages in
whatever state to PyPI over the needs of a
On Thu, Jun 17, 2010 at 3:58 PM, Jess Austin jess.aus...@gmail.com wrote:
In response, a question: is there anyone who supports this radical policy
change who is NOT a zc.buildout user?
I'm a zc.buildout user, and I *don't* support this policy change.
This change is entirely unnecessary.
Hi,
Andreas Jung wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I propose a policy change for packages registered with PyPI:
- packages registered on PyPI have at least one release
- one release of registered package on PyPI _must_ contain
a valid source code
51 matches
Mail list logo
