René Dudfield wrote:
On Wed, Nov 4, 2009 at 9:55 AM, M.-A. Lemburg m...@egenix.com wrote:
Regarding the usefulness of such a feature, take the PIL package
as example:
http://pypi.python.org/pypi/PIL/1.1.6
Package rating (3 votes): 4.667
* 4 points: 1 vote
* 5 points: 2
Laura Creighton wrote:
In a message of Wed, 04 Nov 2009 20:13:45 +0100, M.-A. Lemburg writes:
snip
That said, I don't think it's a good idea to try to reinvent a
wheel that has already been invented many times over. Just look at
the successful systems running on e.g. Amazon and eBay. We
Martin v. Löwis wrote:
I just started a poll on the PyPI rating system, at
http://pypi.python.org/pypi
I'll announce it more widely tomorrow.
I think the poll is missing an important option:
[ ] Allow package owners to disallow comments and/or ratings.
But more importantly: how does that
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Martin v. Löwis wrote:
I'll announce it more widely tomorrow.
I think the poll is missing an important option:
[ ] Allow package owners to disallow comments and/or ratings.
:-( Why didn't you add this to the wiki page in the past days?
Sorry
Chris Withers wrote:
Martin v. Löwis wrote:
But yes, if you have a way, please reduce my votes to one ;-)
Done! Let me know if whether I missed any accounts, and revote if I
indeed found them all.
Can you please document here what you've done to ensure there are no
duplicate votes from
P.J. Eby wrote:
At 08:15 PM 11/14/2009 +0100, M.-A. Lemburg wrote:
Chris Withers wrote:
Martin v. Löwis wrote:
But yes, if you have a way, please reduce my votes to one ;-)
Done! Let me know if whether I missed any accounts, and revote if I
indeed found them all.
Can you please
Georg Brandl wrote:
Is the plan to eventually disable non-OpenID authentication?
I hope not.
Same here.
This whole OpenID thing appears to introduce more problems than
it solves.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Nov 16 2009)
Martin v. Löwis wrote:
Well, python-openid is written in Python, so it should be possible
to add whatever special functionality you need.
For this, I would like to see contributions.
I found myself that it is absolutely necessary to understand the actual
message flow, so I couldn't have
M.-A. Lemburg wrote:
Martin v. Löwis wrote:
However, it is not clear how this is deployed on the
pypi.python.org server. Is there a staging installation
to be used for testing ?
See
http://wiki.python.org/moin/CheeseShopDev
Thanks for the link... I should have searched for CheeseShop
Martin v. Löwis wrote:
I'm getting a permission denied when trying to do a checkout
using this URL (taken from the wiki page):
svn+ssh://svn.python.org/data/repos/packages/trunk/pypi
Has the URL changed or do I have to use some other setup
on the client side than for Python SVN access ?
Chris Withers wrote:
M.-A. Lemburg wrote:
Ok, thanks, got that working... there's just a minor nit:
orig/SVN-PyPI make checkout
Error validating server certificate for 'https://svn.python.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate
M.-A. Lemburg wrote:
Chris Withers wrote:
M.-A. Lemburg wrote:
Ok, thanks, got that working... there's just a minor nit:
orig/SVN-PyPI make checkout
Error validating server certificate for 'https://svn.python.org:443':
- The certificate is not issued by a trusted authority. Use
Martin v. Löwis wrote:
Yes, you could have distutils generate most of those fields,
except for the URL and comment.
What's the use case for these new data? Is this for files
also hosted at PyPI, or for files hosted elsewhere? Who would
use that information, and what for?
As mentioned in
Martin v. Löwis wrote:
The poll is now closed, with these results
Allow ratings and comments on all packages (status quo) 237
Allow package owners to disallow comments (ratings unmodified). 139
Allow comments, but only send them to package owners (ratings
unmodified). 33
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
Martin v. Löwis wrote:
I'd like to extend PyPI to also provide support for listing
files on other servers as well as making it possible for
the package manager tools to automatically select the right
installation file for the intended target platform.
In such a scenario, how do people get
Martin v. Löwis wrote:
ISTM that it would be better to be able to add new such URLs one
by one, e.g. through a web form.
I don't think that's a feasible approach, e.g. eGenix typically
creates around 50 distribution files for every single release
of a product.
In most cases, only the
Ben Finney wrote:
Howdy all,
The new wording is one that I can't agree to:
=
[…]
+ liContent is restricted to Python packages and related
information only./li
+ liAny content uploaded to PyPI is provided on a
non-confidential basis./li
+ liThe
VanL wrote:
Doug Hellmann wrote:
We have to grant the PSF the rights to distribute the files if we're
uploading them to be hosted on PyPI. Does the new wording imply that
we're licensing the use of that code under those terms, or just
granting distribution rights the file containing the
Noah Kantrowitz wrote:
VanL wrote:
Doug Hellmann wrote:
We have to grant the PSF the rights to distribute the files if we're
uploading them to be hosted on PyPI. Does the new wording imply
that
we're licensing the use of that code under those terms, or just
granting distribution rights the
VanL wrote:
M.-A. Lemburg wrote:
Those are likely only a handful of users who'd need the
added permissions and it doesn't explain the need for
an irrevocable license.
The irrevocability is there to protect the PSF. It is so that no one can
claim later that they got mad at the PSF
Steve Holden, Chairman, PSF wrote:
Adding a Google-like clause might make us seem less Draconian.
Here's a proposal for a less controversial text based on the Google
terms:
PyPI is a service provided by the PSF. In order to be able to distribute the
content you upload to
PyPI to web site
Terry Reedy wrote:
M.-A. Lemburg wrote:
Steve Holden, Chairman, PSF wrote:
Adding a Google-like clause might make us seem less Draconian.
Here's a proposal for a less controversial text based on the Google
terms:
I like the third part better.
Thanks.
PyPI is a service provided
Tarek Ziadé wrote:
On Thu, Jan 7, 2010 at 10:29 PM, Brad Allen bradallen...@gmail.com wrote:
On Thu, Jan 7, 2010 at 2:40 PM, P.J. Eby p...@telecommunity.com wrote:
As for projects: fine with me; PyPI would then be the Python Project
Index.
+1
If this gets general agreement, there are
Brad Allen wrote:
On Thu, Jan 7, 2010 at 3:51 PM, M.-A. Lemburg m...@egenix.com wrote:
I don't think we need to change anything - most Python software
components come as Python packages nowadays, so the terminology
'package' we've used all these years is correct.
Do you mean only 'package
Hi Steve,
has there been any progress on this ?
M.-A. Lemburg wrote:
Steve Holden, Chairman, PSF wrote:
Adding a Google-like clause might make us seem less Draconian.
Here's a proposal for a less controversial text based on the Google
terms:
PyPI is a service provided by the PSF
-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
regards
Steve
M.-A. Lemburg wrote:
Hi Steve,
has there been any progress on this ?
M.-A. Lemburg wrote:
Steve
Tarek Ziadé wrote:
On Wed, Jan 20, 2010 at 8:06 PM, M.-A. Lemburg m...@egenix.com wrote:
Steve Holden wrote:
Agreed. Until this issue is resolved we can't allow (public) third-party
mirrors. Given the recent adverse reactions to PyPi changes we should be
careful not to cause any further
Martin v. Löwis wrote:
Steve Holden wrote:
Agreed. Until this issue is resolved we can't allow (public) third-party
mirrors. Given the recent adverse reactions to PyPi changes we should be
careful not to cause any further offense.
I quite disagree on that statement; I see the issue of
Martin v. Löwis wrote:
Sure, the PEP can be used as basis for the decision process, but
someone still has to make the decision to add a mirror or not
and these people should be appointed to by the PSF - much like we
have an infrastructure committee to see after the python.org site.
The
Steve Holden wrote:
Tarek Ziadé wrote:
2010/1/20 Martin v. Löwis mar...@v.loewis.de:
Of course, there's also a human dimension : we suppose that the people
running the mirror are people we can trust because they can
technically do malicious things in the mirror since we don't really
have any
Tarek Ziadé wrote:
On Thu, Jan 21, 2010 at 5:29 PM, M.-A. Lemburg m...@egenix.com wrote:
[..]
Sure, we could do all those things, but such a process will
cause a lot of admin overhead on part of the PSF.
Which process ? the non-web mirroring requires no effort/work from the PSF
Tarek Ziadé wrote:
On Thu, Jan 21, 2010 at 8:08 PM, M.-A. Lemburg m...@egenix.com wrote:
[..]
Those scripts already exist and are in usage in the tools that are
mirroring pypi. They are not rsync but http calls, but that's about it.
Ok, so that wheel has already been reinvented :-)
That's
Martin v. Löwis wrote:
Like I said: the PEP can be used to document the technical requirements
of being accepted as official mirror, but it doesn't cover any
of the legal requirements the PSF will need to put in place in
order to prevent unofficial mirrors
Ok - as we are discussing official
Martin v. Löwis wrote:
What about restricting the mirrors to the non web part in that case ?
I think MAL is talking about a completely different setup: the
unofficial mirror. The unofficial mirror doesn't follow any protocol;
it's just a mirror of PyPI using the standard API to fetch all
Martin v. Löwis wrote:
OK. That's not what I understood since he proposed a cloud system run
by the PSF for the PyPI mirrors. Which implied (to me) those were
official mirrors.
For some reason (which I don't understand) MAL is opposed to the notion
of mirrors. If the complaints about a
Martin v. Löwis wrote:
In order to make it clear that PyPI data may only be mirrored
for redistribution with PSF authorization, we need to add proper
notices to PyPI and also prevent such mirroring technically
(if possible).
However, I don't think this is factually the case: *anybody*
can
Martin v. Löwis wrote:
The second version does seem much more user-friendly, somehow, and
should calm fears about potential abuse of content by the Foundation.
Are we going to go with that?
Not without legal advise. I would hope that users will also get
permission to make copies of the
Martin v. Löwis wrote:
Terry Reedy wrote:
On 1/23/2010 5:03 AM, Martin v. Löwis wrote:
Indeed, that's what we are discussing here. And, I can only
repeat myself: anybody can download the data and redistribute
it in any way they like. This is how it is, and how it should
be.
Many sites
Tarek Ziadé wrote:
Hello,
The Softpedia website sends an email to everyone that register or
uploads something at PyPI. This is clearly a spam and their website
don't care about our projects.
I am not sure if they use the PubSubHubbub thing, but I was wondering
how we could prevent these
Tarek Ziadé wrote:
On Thu, May 6, 2010 at 4:50 PM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
Hello,
The Softpedia website sends an email to everyone that register or
uploads something at PyPI. This is clearly a spam and their website
don't care about our projects.
I am
Tarek Ziadé wrote:
On Thu, May 6, 2010 at 5:18 PM, M.-A. Lemburg m...@egenix.com wrote:
[..]
Sorry, perhaps I wasn't clear: when uploading things to PyPI
you accept the PyPI terms. These terms currently allow anyone
to take the data from PyPI and publically redistribute it
without any
Noah Kantrowitz wrote:
I think most FOSS authors are aware that putting their email in a package is
effectively putting it in the clear on the internet. I think we have come
beyond the days of noah (at) coderanger [dot] net and all those silly
tricks that were popular not too long ago. If
Noah Kantrowitz wrote:
On May 7, 2010, at 12:47 AM, M.-A. Lemburg wrote:
Noah Kantrowitz wrote:
I think most FOSS authors are aware that putting their email in a package
is effectively putting it in the clear on the internet. I think we have
come beyond the days of noah (at) coderanger
Noah Kantrowitz wrote:
On May 7, 2010, at 12:57 AM, M.-A. Lemburg wrote:
Noah Kantrowitz wrote:
On May 7, 2010, at 12:47 AM, M.-A. Lemburg wrote:
Noah Kantrowitz wrote:
I think most FOSS authors are aware that putting their email in a package
is effectively putting it in the clear
Chris Withers wrote:
...would be good to know what brought it down before and what has
brought it down again.
It works for me.
As an interim solution, what do I need to do to get access to the box
running PyPI so I can get in and investigate/restart Apache?
Since PyPI is a rather essential
Tarek Ziadé wrote:
On Fri, Jun 11, 2010 at 11:06 PM, M.-A. Lemburg m...@egenix.com wrote:
Martin v. Löwis wrote:
For a smaller project, start putting mirror support into setuptools or
distribute; this would make short (several hours) outages less severe
for the class of users that want
Martin v. Löwis wrote:
I think it overlaps a bit the PEP goal, which is to set up a network
of mirrors,
and have them listed in the PyPI DNS so clients can switch from one
mirror
to another.(and even do geoloc!)
JFTR, this already exists. a.mirrors.pypi.python.org and
Mathieu Leduc-Hamel wrote:
Agreed, that's why I think it would be useful to simply put
all meta data into a SQLite database file and ship that as
static file as well. Local clients could then download the
database file (probably only a few MB) and work on it locally.
I don't think it would
As mentioned, I've been working on a proposal text for the cloud idea.
Here's a first draft. Please have a look and let me know whether I've
missed any important facts. Thanks.
I intend to post the proposal to the PSF board (of which I'm a member,
in case you shouldn't know) and to have it vote
Mathieu Leduc-Hamel wrote:
To continue the discussion about a rewrite or a cleanup of the Pypi
codebase, I'm from Montreal-Python usergroup and I'm say that yes at the
first the current codebase of pypi seem to be very unclear and difficult to
maintain.
But it's not an impossible mission
Steven D'Aprano wrote:
On Tue, 15 Jun 2010 09:49:03 pm M.-A. Lemburg wrote:
As mentioned, I've been working on a proposal text for the cloud
idea. Here's a first draft. Please have a look and let me know
whether I've missed any important facts. Thanks.
I think the most important missed fact
avoids.
On Tue, Jun 15, 2010 at 1:49 PM, M.-A. Lemburg m...@egenix.com wrote:
PyPI is currently run from a single server hosted in The Netherlands
(ximinez.python.org). This server is run by a very small team of sys
admin.
As Martin von Löwis said, this already exists
Michael Crute wrote:
On Tue, Jun 15, 2010 at 7:49 AM, M.-A. Lemburg m...@egenix.com wrote:
As mentioned, I've been working on a proposal text for the cloud idea.
Here's a first draft. Please have a look and let me know whether I've
missed any important facts. Thanks.
What about a set
Tarek Ziadé wrote:
On Tue, Jun 15, 2010 at 6:02 PM, M.-A. Lemburg m...@egenix.com wrote:
Alexis Métaireau wrote:
Hello,
Firstly, as Tarek said in another thread, I'm afraid this kill the PEP381
about making a mirroring infrastructure.
Having a infrastructure hosted on a cloud platform may
Jesus Cea wrote:
On 15/06/10 13:49, M.-A. Lemburg wrote:
Server side: upload cronjobs
Since the /simple index tree is currently being created dynamically,
we'd need to create static copies of it at regular intervals in order
to upload the content to the S3
Tarek Ziadé wrote:
On Tue, Jun 15, 2010 at 7:34 PM, M.-A. Lemburg m...@egenix.com wrote:
[..]
So I think it would be better to focus on PEP 381, and make those
existing mirrors comply with it. And maybe work on the legal issues
you've mentioned
That can all happen in parallel.
I really
Martin v. Löwis wrote:
I read pep 381 long time ago and I don't remember how/when a mirror
would update, but I do remember it doesn't mandate digital signatures
(signed by pypi central node, verified by setuptoolsfriends). That is a
big gap, in my opinion.
The PEP doesn't explain the
Martin v. Löwis wrote:
PyPI itself has in recent months been mostly maintained by one
developer: Martin von Loewis. Projects are underway to enhance PyPI
in various ways, including a proposal to add external mirroring (PEP
381), but these are all far from being finalized or implemented.
Tarek Ziadé wrote:
On Tue, Jun 15, 2010 at 10:14 PM, M.-A. Lemburg m...@egenix.com wrote:
I'm not trying to compete with your mirror PEP, just trying
to solve a problem.
We are trying to solve the same problem, aren't we ?
Sure, but the intent is not to compete with the PEP. Even
Antoine Pitrou wrote:
M.-A. Lemburg mal at egenix.com writes:
Setting up some Zenoss or Nagios monitoring system to take
care of monitoring the PyPI server (and our other servers)
would be a separate project.
Just for the record, I would mention that someone started a rewrite
Antoine Pitrou wrote:
Tarek Ziadé ziade.tarek at gmail.com writes:
And we happen to have this network already: lots of people
will host a PyPI mirror as soon as it's easy to set one imho.
You must be careful that the mirrors are properly managed and administered,
though. Having
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:
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
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
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
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
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
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
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
Simon de Vlieger wrote:
On 17 jun 2010, at 22:44, Martin v. Löwis wrote:
In web app land, supported browsers usually means the ones the
designer targets: e.g., including IE= 7 in the list means that the
designer doesn't have to include workarounds for stupid glitches in
earlier IEs (or
P.J. Eby wrote:
At 11:10 AM 6/18/2010 +0200, M.-A. Lemburg wrote:
Martin v. Löwis wrote:
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
After the discussions, we've had on the catalog sig, I have updated
the proposal to include comments and clarifications regarding the setup
and it's relationship to the mirror PEP (see the end of the proposal).
While I don't think that the proposal has an influence on whether
or when PEP 381 gets
Alexis Metaireau wrote:
On Tue, 2010-07-27 at 09:52 +0100, Chris Withers wrote:
there is now a way to request release information in JSON,
see http://tinyurl.com/38lefsp
That's indeed cool, and useful, but we can't rely on this while
crawling, too bad this JSON is not replicated on the
Martin v. Löwis wrote:
Thoughts?
I've been thinking that *.pypi.python.org should always
yield A records, not CNAMEs.
+1
It may be that this becomes difficult with Google appengine,
though.
There's no rule without exception :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python
Martin v. Löwis wrote:
Am 27.07.2010 22:46, schrieb M.-A. Lemburg:
Martin v. Löwis wrote:
I'll be implementing a feature for PyPI where you can POST
to a certain action (revdownload), and then PyPI will POST
the file requested to an URL that was passed; this is need
to make blobs work
Martin v. Löwis wrote:
1/ The obsolete field could be used to say this is the new version of
X, like the name of the project has changed. So the new version
obsoletes the old one. Using this field, I think that the installers
should remove the old releases (by prompting the user).
-1.
The
Tarek Ziadé wrote:
On Mon, Aug 23, 2010 at 1:24 PM, M.-A. Lemburg m...@egenix.com wrote:
..
In case of obsoletes, it _should_ also be possible to install both
of them simultaneously. Maybe some other other distribution depends
on the original one, and can't work with the new one.
Agreed
Alexis Métaireau wrote:
Le 08/24/2010 05:12 PM, M.-A. Lemburg a écrit :
I do see a problem with such a general purpose conflicts field,
regardless of what the use case is. If the installer prevents
packages from being installed by means of defining such
a conflicts field, this can be used
Martin v. Löwis wrote:
So you are fine with publishing slightly incorrect metadata at PyPI
? I am not.
I really have no intuition for in how many cases the data will be
incorrect. However, if users find that the data is incorrect for
specific package, they ought to complain to the
Martin v. Löwis wrote:
IMHO, most of this has been resolved by means of the XML-RPC
interface via the .release_data() method:
http://wiki.python.org/moin/PyPiXmlRpc
If there's something missing, we should add it there.
Very clearly, most of egg-info is missing there. However, I
sense
Tarek Ziadé wrote:
On Mon, Sep 20, 2010 at 9:26 PM, Martin v. Löwis mar...@v.loewis.de wrote:
IMHO, most of this has been resolved by means of the XML-RPC
interface via the .release_data() method:
http://wiki.python.org/moin/PyPiXmlRpc
If there's something missing, we should add it there.
wander.lairson wrote:
2011/1/4 Andreas Jung li...@zopyx.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Huh?
http://pypi.python.org/pypi/pyusb/0.4.2
lists an email
and
http://sourceforge.net/users/wander_lairson
has a See me a message link.
In addition: this project has a
Tarek Ziadé wrote:
On Wed, Jan 26, 2011 at 3:36 AM, Brian Jones bkjo...@gmail.com wrote:
...
http://mail.python.org/pipermail/catalog-sig/2010-September/003301.html
I'm not positive we're on the same page. You seem to be talking about adding
some specific new data in a specific way to the
Tarek Ziadé wrote:
Oh... so what about this:
- PyPI publishes setuptools metadata, but in Metadata 1.2 format. The
conversion is pretty simple, it's just translating the requires.txt
into PEP 345 fields.
- We add a marker so we know that those metadata are from setuptools
That way, PyPI
Baiju M wrote:
On Sun, Jan 30, 2011 at 11:48 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
But many of the packages are not really existing in PyPI:
http://paste.pocoo.org/raw/329292/
Is there any auto-generated list of these packages
somewhere ?
I don't know what a not really existing
Martin v. Löwis wrote:
As for a big link: if you think your page should have one, you are free
to make it yourself already.
Sure but,
1/ I have never asked for the Downloads ↓ link either, but the UI
did add it, and it's really more ergonomic.
2/ I have never asked for Latest Version:
Chris Withers wrote:
Hi,
Any chance we could put a block in place on packages that mention this
phrase?
Has anyone had any joy tracking down the author of the book that
resulted in this avalanche of junk? At the very least they could publish
an errata explaining their horrific
Chris Withers wrote:
On 24/03/2011 08:58, Ronald Oussoren wrote:
On 24 Mar, 2011, at 7:46, Chris Withers wrote:
Hi,
Any chance we could put a block in place on packages that mention
this phrase?
Has anyone had any joy tracking down the author of the book that
resulted in this avalanche
Daniel Greenfeld wrote:
Hey guys,
I get a 404 when I go here which is off the package upload page:
http://www.python.org/doc/dist/package-upload.html
Also, when I go to the tutorial I see instructions pointing at
easy_install. I thought the move was towards Pip. See
Daniel Greenfeld wrote:
Here is something that we all might find useful.
When Python Packages launches it will be hitting the XMLRPC server
over 10,000 times a day - at least once per listed package. Django
Packages already hits PyPI about 3000 times a day. We'll be doing this
in a
Martin v. Löwis wrote:
Am 28.04.2011 10:26, schrieb M.-A. Lemburg:
Martin v. Löwis wrote:
I came up with a key rollover scheme for the server key on PyPI.
[...]
The key rollover will be logged in the PyPI journal,
using an empty package name and an empty release. TOOLS USING
THE JOURNAL
Tres Seaver wrote:
On 05/13/2011 01:12 PM, exar...@twistedmatrix.com wrote:
On 03:21 pm, mer...@netwok.org wrote:
Le 12/05/2011 21:04, exar...@twistedmatrix.com a ýcrit :
On 03:57 pm, ziade.ta...@gmail.com wrote:
[...]
I'll definitely do something in distutils2 but maybe someone has a
John J Lee wrote:
On Mon, 16 May 2011, M.-A. Lemburg wrote:
[...]
Just to clarify: creating an sdist really only means copying
over the files from the MANIFEST into a temporary dir and then
running tar or zip on the temporary directory. You can tell
distutils to keep the temporary dir around
M.-A. Lemburg wrote:
The chance of two consecutive runs of sdist creating different
archives is rather small, compared to those sources of error.
That said, it's easy to get the upload command to use an
already created distribution file for the upload: just
add a new distutils command which
John J Lee wrote:
On Mon, 16 May 2011, M.-A. Lemburg wrote:
That said, it's easy to get the upload command to use an
already created distribution file for the upload: just
add a new distutils command which sets .distribution.dist_files
to what list of files you want to upload
Carl Meyer wrote:
On 05/21/2011 01:58 PM, M.-A. Lemburg wrote:
Carl Meyer wrote:
On 05/21/2011 03:00 AM, Chris Withers wrote:
It install packages with C extensions yet?
Sure, I do it every day. You just need a compiler.
... and all the external dependencies such a package may have.
pip
Chris Withers wrote:
This package:
http://pypi.python.org/pypi/PDFTron%20PDFNet%20SDK%20for%20Python/5.7
...feels a lot like spam.
The mention of Python if you follow through to their page is pretty
minimal. Not sure it belongs on PyPI.
What do others think?
Have you tried
Martin v. Löwis wrote:
Which makes me wonder, why is it that PyPI doesn't use a universally
accepted SSL cert instead of the CAcert one? Note: I'm a CAcert assurer
myself but would prefer using a cert by one of the commercial CAs for
the sake of the users.
Any opinions?
Primarily because
1 - 100 of 226 matches
Mail list logo
