I'm making a release of my project today, and I noticed that the MSI created
by Python 2.7 when doing `bdist_msi` does not seem to be attached to a
specific Python version.
Is it safe to supply it for users of Python 2.5-2.7? (My package is
pure-Python.)
When uploading to PyPI, I'm forced to choose a single Python version for the
MSI. What do I do? I don't want people to be mislead to think that it's an
MSI only for 2.6 when it works for 2.5-2.7. I tried uploading the same file
for all three versions, but PyPI didn't allow this, telling me I already
uploaded that file.
Please help, I want to make a release today.
Thanks,
Ram.
At 05:39 AM 12/23/2010 +0000, hm wrote:
>I have downloaded setuptools-0.6c11.win32-py2.5.exe and tried to
>install it on Windows 7 (64 bit). I have an existing Python
>installation. The setuptool recognizes the path, however, puts a
>quote around the path. The problem is that it also carries the
>quotes around the Python path in the installation directory and
>makes a path like:
>
>"C:\Python25\"\Lib\site-packages\
>
>This is an invalid path and in the next step the installer complains
>that cannot install the files in the provided path. The setuptool
>also does not allow editing this path. Any help is appreciated, asap.
This sounds like a problem with the distutils installer for
Windows. Have you tried installing any other Python .exe's from
PyPI, and do they have the same problem?
New submission from hm <hmotahary(a)yahoo.com>:
I have downloaded setuptools-0.6c11.win32-py2.5.exe and tried to install it on Windows 7 (64 bit). I have an existing Python installation. The setuptool recognizes the path, however, puts a quote around the path. The problem is that it also carries the quotes around the Python path in the installation directory and makes a path like:
"C:\Python25\"\Lib\site-packages\
This is an invalid path and in the next step the installer complains that cannot install the files in the provided path. The setuptool also does not allow editing this path. Any help is appreciated, asap.
Thank
Hamid
----------
messages: 569
nosy: hm
priority: bug
status: unread
title: setuptools-0.6c11.win32-py2.5 python path recognition problem
_______________________________________________
Setuptools tracker <setuptools(a)bugs.python.org>
<http://bugs.python.org/setuptools/issue119>
_______________________________________________
Hello,
I've got a strange issue with version resolution when using
zc.buildout; I don't know if it's zc.buildout specific or it's caused
by something which is done by distribute.
The example code can be fetched from there:
hg clone https://Alan@bitbucket.org/Alan/buildoutversionissue
End of output result:
Installing test.
While:
Installing test.
Error: There is a version conflict.
We already have: zope.testrunner 4.0.0
but asd 0.1.0 requires 'zope.testrunner==4.0.0b1'.
If you check within the downloaded eggs, you'll see there's no egg
requiring zope.testrunner 4.0.0; there's just zc.recipe.testrunner
requiring "zope.testrunner", without any version.
if egg A requires "foolib" while egg B requires "foolib==1.0.0", and
the latest available version of foolib is "1.0.1", then a version
conflict error will arise; it's just as if a "naked" egg dependency is
pinned to the latest available version of a package.
Is that an intended behaviour? I don't seem to find any evidence of
that in distribute or distutils doc. Although specifying a dependency
without a version shouldn't be a good practice, it seems quite common
- mostly because many people have got full control of the pypi section
on their own repo and they can decide what's offered there, so they
just specify "mydependency" on their other projects. I think it's
quite a wide assumption, by the way.
Also, this is not the usualy way dependencies are resolved in most
package managers. When using yum (and apt should be quite similar),
something like that happens:
Scenario:
two versions of "mydep" are available: mydep 1.0.0 and 1.0.1
"foo" depends just on mydep
"bar" depends on mydep 1.0.0
If I just want to install "foo", I'll get foo and mydep 1.0.1 on my
system. But if I try installing both, I'll get foo, bar and mydep
1.0.0, because that will be resolved as the best way to handle all
dependencies.
Any comment?
--
Alan Franzoni
--
contact me at public(a)[mysurname].eu
Something bugs me about virtualenv, distribute, development, and testing. I
figure I'm probably doing something wrong and that y'all will be able to set
me straight.
I'm working on a new tool called pkgme[1]. It uses distribute and recommends
using virtualenv for development. After activating the virtualenv you can do
'python setup.py develop' and do convenient in-place editing so that your
changes to the source show up immediately in the running environment. So far
so good.
However, when I want to run the test suite, it does the equivalent of a
'python setup.py build' and then runs the tests out of the
build/lib.{platform}-{version} directory. This actually screws with our tests
because (at least currently) the tests are looking for shell scripts and other
programs that live in our tree, but are not part of the Python packaging, so
don't get built or installed by setup.py. When we do filesystem introspection
to try to find the scripts to exec them, it will work when running in develop
mode, but fail in the tests, since __file__ points into build/lib.* instead of
the source tree.
So I'm wondering if other folks have hit similar problems and what best
practices can be recommended to deal with this problem. I can think of
various hacks around the problem, but don't want to reinvent the wheel.
Or do you think that 'python setup.py test' should use the in-place tree and
this is Just A Bug?
Cheers,
-Barry
[1] https://launchpad.net/pkgme
Hi,
i'm new to this list. I hope this question is pertinent to the list, if not
please address me to a more appropriate one.
I'd like to understand what is the preferred way to cope with demo
examples/directory while packaging.
I have a classic structure
sqlkit-N.n/
sqlkit/
setup.py
MANIFEST.in
demo/
My goal would be to have a setup so that 'python setup.py sdist' would
package also the demo, so that 'python setup.py sdist upload' could be all I
need to do to publish it. Is this a reasonable goal? I ask this as I
wouldn't know where to place the demo in the target installation. Under
Linux that I know pretty well a demo would be under
/usr/(local/)/share/doc... but where sould it be placed under Windows? Is
this simething that should be taken care of by setuptools?
Searching in the docs I never found the 'demo' word and google was not very
usefull too.
Any hint is appreciated.
thanks a lot
sandro
--
Sandro Dentella *:-)
http://www.reteisi.org Soluzioni libere per le scuole
http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy
Hello all. I'm wondering if there is still any effort behind the stdeb
package development. I find it super handy for what I do at work, and I'm
wondering if there's going to be canonical support and/or further package
development done in this area. - Sean
Hello
I've just been able to properly identify why pkg_resources at times issues
an obtuse (to me at least) warning along these lines: "Module <module> was
already imported from <filename>, but <egg> is being added to sys.path". It
turns out that really that a non-egg distribution is on the module search
path before a corresponding egg distribution. If you run bin/test.py in the
attached case, you should see a demonstration of the issue.
Right now, it bit me when testing under a continuous integration slave on a
machine where the tested project is also installed as an egg. I couldn't for
the life of me understand why this warning was being issued, when I couldn't
see it on my development machine. Not before painstakingly debugging
pkg_resources, did it dawn on me that pkg_resources only complained on the
test machine since there was no egg metadata in the source tree (whereas in
my development source tree there is). Until debugging pkg_resources I
actually didn't know that a directory (i.e., with Python packages) is
considered an egg if it has a .egg-info file (with egg metadata) in it. I
just hadn't had the motivation yet to learn the egg technology that well.
Considering that pkg_resources' rationale for issuing this warning is so
difficult to derive from the message, may I suggest please that we modify
the message somewhat for added clarity? If it were more explicit, it should
be much easier to rectify the warning's cause. My suggestion is a message on
this form: "'<egg>' is being added to sys.path, but contained module
'<module>' was already imported from '<filename>'. Could this be a non-egg
distribution?". From such a warning, it should be possible to derive that
the module may have been imported from what is not considered by
pkg_resources an egg distribution (such as a clean source tree).
Thanks,
Arve
I'm a newbie to Python, so please be patient with me....
1) On Ubunto 10.10 I used sudo to install python-setuptools then used
easy_install to install zc.buildout.
2) I then logged on as a different user (who is not able to sudo) to create
my first buildout project.
plonesvc@ubuntu:~$ mkdir exercise1
plonesvc@ubuntu:~$ cd exercise1/
plonesvc@ubuntu:~/exercise1$ buildout init
Creating '/home/plonesvc/exercise1/buildout.cfg'.
Creating directory '/home/plonesvc/exercise1/bin'.
Creating directory '/home/plonesvc/exercise1/parts'.
Creating directory '/home/plonesvc/exercise1/eggs'.
Creating directory '/home/plonesvc/exercise1/develop-eggs'.
Generated script '/home/plonesvc/exercise1/bin/buildout'.
3) I downloaded the bootstrap.py from svn
plonesvc@ubuntu:~$ wget \
http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py
4)And tried to run the bootstrap - which failed:
plonesvc@ubuntu:~/exercise1$ python bootstrap.py
Downloading
http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg
Traceback (most recent call last):
File "bootstrap.py", line 256, in <module>
ws.require(requirement)
File "/tmp/tmpCfYQ3c/setuptools-0.6c11-py2.6.egg/pkg_resources.py", line
666, in require
File "/tmp/tmpCfYQ3c/setuptools-0.6c11-py2.6.egg/pkg_resources.py", line
565, in resolve
pkg_resources.DistributionNotFound: zc.buildout==1.5.2
5) I've tried searching for the error via google without success.
6) I have subsequently installed virtual env and setup a new buildout
project and run the bootstrap.py successfully. Which, is great but I want
to know why I wasn't able to do this without virtual env?
I was wondering if someone could explain why step 4 above failed. What was
the reason for this?
Simon