Visual Studio 2008
I'm trying to compile a package (Twisted, as it happens) for Python 2.6
but having no joy:
Setting environment for using Microsoft Visual Studio 2008 x86 tools.
C:\Program Files\Microsoft Visual Studio 9.0\VC\bin>w:
W:\Twisted-10.0.0>c:\Python26\python.exe setup.py build
error: Unable to find vcvarsall.bat
What am I doing wrong?
At 05:36 AM 5/4/2010 -0700, Kent wrote:
>Something seems to have changed with a recent release of setuptools.
>I recently upgraded to -0.6c11 from c9.
>Under c9, my setup.cfg could specify this:
>find_links = ../../thirdparty
>in order to direct setuptools to install from the ../../thirdparty
>directory instead of searching the internet. This worked for my
>project's dependencies and the dependencies' dependencies.
>Now, under c11, settings in the setup.cfg only pass to my project's
>direct dependencies (install_requires= list).
>They no longer are passed to those dependencies' dependencies.
>What happened? I've googled and googled and am having no luck. Is my
I need more information than this to understand what you mean. Are
you talking about running from "setup.py install", or using
"easy_install myproject"? What exactly are the dependencies, and the
contents of the thirdparty directory?
>P.S. I also can't find an official PEAK software setuptools forum...
>is this the best forum to ask this question?
"Please use the
mailing list for questions and discussion about setuptools"
Something seems to have changed with a recent release of setuptools.
I recently upgraded to -0.6c11 from c9.
Under c9, my setup.cfg could specify this:
find_links = ../../thirdparty
in order to direct setuptools to install from the ../../thirdparty
directory instead of searching the internet. This worked for my
project's dependencies and the dependencies' dependencies.
Now, under c11, settings in the setup.cfg only pass to my project's
direct dependencies (install_requires= list).
They no longer are passed to those dependencies' dependencies.
What happened? I've googled and googled and am having no luck. Is my
Thanks to anyone who can help.
P.S. I also can't find an official PEAK software setuptools forum...
is this the best forum to ask this question?
Currently setuptools only support a ``tag-svn-revision`` option.
However I use Mercurial, and I would like to tag hg revisions.
Looking at setuptool sources, it should not hard to add a new
``tag-revision`` option, used, as an example:
In egg_info command class, then, the tags method could do something like:
version = ''
for ep in iter_entry_points(
version += '-r%s' % ep.load()()
# Only use first entry point
version += '-r%s' % get_pkg_info_revision()
import time; version += time.strftime("-%Y%m%d")
The current ``--tag-svn-revision`` will become an alias for
``--tag-revision=svn``, and support will be directly available in
I don't know if setuptools is still under development (this topic seems
quite confused, for me), but can I write a patch, hoping that it will be
Where should I send the patch?
Thanks for the quick resolution of this, I just wanted to mention
a problem I ran into with these that I don't think I saw reported
in the archives.
After working around the 'cannot import warnings' problem, I was
getting errors where buildout complained about a missing find-links
parameter. I set that to the empty value:
And then got the same thing with another one, can't remember which.
I set that to the empty value, and then ran into a traceback about
a parameter, I think it was 'include_site_packages' being passed to
the working_set function that it didn't support. Sorry I can't be
more specific about that, I was rebuilding my virtualenv several
times, when it started working again thanks to the b2 releases.
Since this was around the time the b2 versions were released,
maybe it was a version mismatch between a b1 and b2 version?
I suspect I've asked this before here but have forgotten the answer, so I
ask again. We currently use easy_install at work to install most/all
third-party packages. This causes problems because sys.path winds up
organized like this:
3rd party stuff, followed by
local stuff, followed by
As the number of third-party packages grows, the startup time for most
applications increases significantly because most of the modules and
packages of interest are actually in the local stuff or the system stuff.
If this was one or two applications running on a single machine it wouldn't
be bad. When you add in NFS and try to start several hundred applications
across a multitude of hosts it's pretty easy to freeze the NFS server for a
non-trivial amount of time and extend startup times significantly.
Our current hack is to comment out the
import sys; new=...
line which easy_install adds to the end of easy-install.pth. That's not
perfect, since the next time a third-party package is installed we have to
remember to do it again. And again. And again. Eventually, no matter how
careful we are about this, someone forgets.
There must be something I can do to mitigate this problem. Can all the
third-party eggs be bundled into a super package of some kind to minimize
all the file stat-ing? Would some other installer (pip? zc.buildout?) do
things differently? Have I maybe missed some flags to easy_install which
would improve things?
Skip Montanaro - skip(a)pobox.com - http://www.smontanaro.net/
I am moving the venue for this discussion on stdeb to the distutils-sig
(from http://bugs.python.org/issue1054967 ). I think this is better
On 4/29/10 9:23 PM, Barry A. Warsaw wrote:
> Manual moving/copying is what I want to avoid. I'd be totally happy with not reinventing the wheel if you think this would be easy to add to stdeb! Specifically: just create debian/ in place and do not build package.
OK, I just added a new command "debianize" to stdeb (git commit 3cac5533
on github). This is currently in the "debianize" branch, which I intend
to merge into the master branch after a bit more review.
> I have a few other minor suggestions, though if you think this isn't the best place to track them, please let me know where to submit them.
In general, the place is "Issues" at http://github.com/astraw/stdeb ,
but I've addressed all the issues below.
> * Add setup.py entry_points so you don't have to use --command-packages
This (and all other dependencies on setuptools) was removed at the
request of the distutils maintainer Tarek Ziadé, who suggested that
depending on setuptools prevented listing stdeb in the stdlib distutils
documentation. "--command-packages" is standard, documented distutils,
and works fine in my experience. If it's convenience you're after, you
can add this option to your ~/.pydistutils.cfg file as documented in the
stdeb README.rst file. I'm not planning on re-introducing the old behavior.
> * Package: shouldn't change dots to dashes. E.g. flufl.enum should be called python-flufl.enum
This should be fixed in git commit 24085bb.
> * Update to Standards-Version: 3.8.3
Thanks for the alert. I'll have a look. Added to the tracker at
> I'm happy to test whatever you come up with.
Great. If you want to write unit testing infrastructure, that'd be great.
Sorry for this reply, but it seems I have some problems at receiving
mails from my gmail account.
I have done some more tests and:
* When installing in the system default site directory, namespace
package work as expected
* When installing in a virtual environment (virtualenv
--no-site-packages), the namespace package is not found; it seems to
be completely ignored
Can someone else confirm that namespace packages do not work with
There is nothing critical I guess, but stdeb on Ubuntu 10.04 gives a
lot of warnings about unknown "buildsystem" option and some others.
Any hints why? Should/could these be fixed?
pydoctor$ python setup.py --command-packages=stdeb.command bdist_deb
Unknown option: buildsystem
dh_testdir: warning: ignored unknown options in DH_OPTIONS
Duplicate specification "O=s" for option "O"
dpkg-deb: warning: 'debian/python-pydoctor/DEBIAN/control' contains
user-defined field 'Python-Version'
dpkg-deb: building package `python-pydoctor' in
dpkg-deb: warning: ignoring 1 warnings about the control file(s)