I'm trying to release my project to PyPI today.
I have three problems:
(1.) I have 4 different forks for my project for Python versions 2.4, 2.5, 2.6
and 3.1. Should they all be on the same name in PyPI?
(2.) I'm trying to upload an MSI. I'm doing `setup.py bdist_msi register
upload`. It builds the project and the setup script finishes, but then I get:
error: garlicsim-0.1: No such file or directory
And no .msi file is uploaded to PyPi. Why?
(3.) I tried uploading my 2.5 fork. It asks me to identify, I do, it gives an OK
response (which doesn't happen unless the identification is right), but then it
claims I didn't identify! Why?
removing 'build\bdist.win32\egg' (and everything under it)
We need to know who you are, so please choose either:
1. use your existing login,
2. register as a new user,
3. have the server generate a new password for you (and email it to you),
Your selection [default 1]: 1
Server response (200): OK
Submitting dist\garlicsim-0.1.zip to http://pypi.python.org/pypi
Upload failed (401): You must be identified to edit package information
removing 'build' (and everything under it)
error: garlicsim-0.1: No such file or directory
On Sat, Nov 14, 2009 at 4:34 PM, Arc Riley <arcriley(a)gmail.com> wrote:
>> Having a "Repository-URL", "Repository-Browse-URL" and a
>> "Bug-Tracker-URL" field in PyPI would be a lot more usefule then
>> comments and ratings.
You mean in the Metadata ? We are currenty working on adding fields in them,
for an upcoming 1.2 version (see PEP 345)
I am crossposting to distutils-sig so we can discuss this point over
there, because I think that would
be a great triple of fields to add in 1.2
What's the best way to delete the "build" directory both before and after
installation, using Distribute? I want to do it so the user will only need to do
"setup.py install", and the build directory will be pre- and post-deleted.
I just found this comment on my blog. People have told me this in
person too, so I believe it is real pain (even if the solution may be
elusive and the suggested solutions may not work). But I don't know
how to improve the world. Is the work on distutils-sig going to be
enough? Or do we need some other kind of work in addition? Do we need
more than PyPI?
---------- Forwarded message ----------
From: dalloliogm <noreply-comment(a)blogger.com>
Date: Fri, Nov 6, 2009 at 8:01 AM
Subject: [Neopythonic] New comment on Python in the Scientific World.
dalloliogm has left a new comment on your post "Python in the Scientific World":
Python is suffering a lot in the scientific word, because it has not a
PyPI is fine, but it is still far from the level of CPAN, CRAN,
Scientists who use programming usually have a lot of different
interests and approaches, therefore it is really difficult to write a
package that can be useful to everyone.
Other programming language like Perl and R have repository-like
structure which enable people to download packages easily, and to
upload new ones and organize them withouth having to worry about
having to integrate them into existing packages.
This is what is happening to biopython now: it is a monolitic package
that it is supposed to work for any bioinformatic problem; but this is
so general that to accomplish that you would need to add a lot of
dependencies, to numpy, networkx, suds, any kind of library.
However, since easy_install is not as ready yet as the counterparts in
other languages, if the biopython developers add too many
dependencies, nobody will be able to install it properly, and nobody
will use it.
Posted by dalloliogm to Neopythonic at November 6, 2009 8:01 AM
--Guido van Rossum (python.org/~guido)
I have created a Wiki page that gives an overview on the PEPs that are
currently drafted and some of the proposals that were mentioned here
on the list.
You can find it at:
I would be happy if you could add your own proposals/ideas or comment on
those that are already present.
.''`. Wolodja Wentland <wentland(a)cl.uni-heidelberg.de>
: :' :
`. `'` 4096R/CAF14EFC
`- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
On Thu, Nov 12, 2009 at 6:59 AM, Tarek Ziadé <ziade.tarek(a)gmail.com> wrote:
> And let's drop the backward compat issues in these discussions, so we
> don't burn out
> in details.
That's the part I don't understand. If backward compatibility is not a
concern, why keeping distutils ? If you change the command and
Distribution class design, what remains of the original code ? You
are changing the API and the implementation (which are quite tangled
with each other in distutils case), almost none of the original code
It really feels to me like you are getting the pain of backward
compatibility without the gains. What am I missing ?
At 03:13 PM 11/11/2009 +0100, Tarek Ziadé wrote:
>But you call it with "install" in your example, meaning that is is
>called at install time, right ?
>Or it is just that you want to get the "--prefix" value finalized and
>computed by the install
>command. If it's the later, I guess you will be able to use the
>upcoming "sysconfig" module,
>that gives you the install schemes, depending on sys.prefix/sys.exec_prefix.
The issue is that setup.py can accept multiple commands on the
command line, and in principle "build_clib" might be being called as
a subcommand of build (and thus of install). So, he needs the
*active* --prefix, either from the command line, config file(s), or
defaults. Simply having an API to get the defaults won't help this.
Really, getting a finalized "install" command object is the only way
to do this correctly in distutils at the moment, and the sysconfig
API won't change that.