setuptools without unexpected downloads

[kyosohma]

MySQLdb and psycopg are two obvious examples I have had to grub around
or produce my own installers for. There's generally some configuration
work to do for packages that have been produced without considering
Windows requirements, and ideally this will be fed back to the developers.

I think you may be oversimplifying a little. Pure Python packages aren't
too problematic, it's mostly the extension modules. Unless a copy of
Visual Studio is available (and we *might* get some cooperation from
Microsoft there) that means resorting to MingW, which isn't an easy
environment to play with (in my occasional experience, anyway).

There's going to be increasing demand for 64-bit implementations too.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

Steve,

We have Visual Studio 2005 at work and my boss is a Python nut, so I
could probably use it. I also have academic versions of VS 6 and 2003
(maybe 2005 too...I forget, it might be 2004) at home as well...I
think I can use those for open source development, although knowing
Microsoft, there's probably something draconian hiding in the EULA
somewhere.

If someone is willing to give me some guidance, I'll give it a try.

Mike

 

[Steve Holden]

Steve,

We have Visual Studio 2005 at work and my boss is a Python nut, so I
could probably use it. I also have academic versions of VS 6 and 2003
(maybe 2005 too...I forget, it might be 2004) at home as well...I
think I can use those for open source development, although knowing
Microsoft, there's probably something draconian hiding in the EULA
somewhere.

If someone is willing to give me some guidance, I'll give it a try.

Mike:

The existing Python Windows installation is, IIRC, produced with VS
2003. Though much work has been done on making a VS2005 version, I do
not believe it has yet been completed. But I don't believe there's
anything horrendous in the EULA waiting to bite us in the ass.

I think I could probably get Microsoft to make low-cost software
available for individuals who were helping the Python community out in
this way (and if not then I might persuade the PSF to apply some funding
if individuals were seen to be committed to the task).

At least as important as individual volunteers to do the packaging work
(and feed back changes to non-Windows implementation teams) is the need
for someone to coordinate all the work done on different packages.
Without someone who has an overall grasp of what's going on such work
might tend to founder. Are you interested in that side of things at all?

I'm happy to give you what guidance I can [off line would probably be
best], but my version of Visual Studio hasn't been used in two months ...

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

 

[Istvan Albert]

behaviour with a specific invocation of 'setup.py'. But how can I
disallow this from within the 'setup.py' program, so my users don't
have to be aware of this unexpected default behaviour?

I don't have the answer for this, but I can tell you that I myself
dislike the auto-download behavior and I wish it worked differently.

I've given up on setuptools/easy-install altogether. It is most
annoying to end up with half a dozen unexpected packages.

The default behavior should be to pop a question with a list of
packages that will be downloaded (and have a flag that bypasses this).
And of course being able to turn off this feature from setup.py.

i.

 

[Fredrik Lundh]

What would it entail to do this? Using py2exe + some installer (like
Inno Setup) to create an installer that basically copies/installs the
files into the site-packages folder or wherever the user chooses?

if the setup.py file is properly built, "python setup.py bdist_wininst"
builds an installer that does exactly that.

ideally, someone doing this would:

1) build EXE installers and EGG:s for a reasonable number of Python
versions (e.g. 2.3 and newer) for selected releases. if possible, using
the same compilers as used for the python.org core distribution.

2) test the installers in some way (at least some kind of "sanity
checking" is necessary; i.e. installing the kit and checking that the
core modules can at least be imported).

3) if necessary, work with upstream providers to fix/improve setup.py
and test code.

</F>

 

[kyosohma]

if the setup.py file is properly built, "python setup.py bdist_wininst"
builds an installer that does exactly that.

ideally, someone doing this would:

1) build EXE installers and EGG:s for a reasonable number of Python
versions (e.g. 2.3 and newer) for selected releases. if possible, using
the same compilers as used for the python.org core distribution.

2) test the installers in some way (at least some kind of "sanity
checking" is necessary; i.e. installing the kit and checking that the
core modules can at least be imported).

3) if necessary, work with upstream providers to fix/improve setup.py
and test code.

</F>

Mr. Lundh,

Holden indicates that VS2003 is the current compiler used for the
official Python distribution. Do you know how to use that program to
compile an exe? I'm assuming the line "python setup.py bdist_wininst"
isn't sufficient since it was an answer to my somewhat naive question.

Thanks,

Mike

 

[Gabriel Genellina]

Holden indicates that VS2003 is the current compiler used for the
official Python distribution. Do you know how to use that program to
compile an exe?

Open the program, press F1 and read the documentation provided by its
vendor, Microsoft.

I'm assuming the line "python setup.py bdist_wininst"
isn't sufficient since it was an answer to my somewhat naive question.

Why not? As F.L. said, if the setup.py is properly built, doing so should
compile and link all the required modules.
Note that it's not *required* to use Visual Studio to compile Python
extensions; any decent compiler would do [provided it links against the
same RTL as used by VS]

This recent blog post contains step-by-step instructions on using free
tools to compile python extensions:
<http://boodebr.org/main/python/build-windows-extensions>

 

[Max Erickson]

This recent blog post contains step-by-step instructions on using
free tools to compile python extensions:
<http://boodebr.org/main/python/build-windows-extensions>
--

....

The package available here:

http://www.develer.com/oss/GccWinBinaries

is quite a lot more straightforward. You do have to be okay with using
GCC 4.1 though. As a bonus, it supports versions of python that link
against several different versions of the Microsoft runtime, rather
than just one.


max

 

[kyosohma]

Open the program, press F1 and read the documentation provided by its
vendor, Microsoft.

Sheesh! MS Documentation would take weeks and weeks to read, let alone
analyze and grok. I was hoping to avoid that, but it was my next step
if I hadn't received an answer.

I'm assuming the line "python setup.py bdist_wininst"
isn't sufficient since it was an answer to my somewhat naive question.

Why not? As F.L. said, if the setup.py is properly built, doing so should
compile and link all the required modules.
Note that it's not *required* to use Visual Studio to compile Python
extensions; any decent compiler would do [provided it links against the
same RTL as used by VS]

F.L. also said to use "the same compilers as used for the python.org
core distribution" if possible.

This recent blog post contains step-by-step instructions on using free
tools to compile python extensions:
<http://boodebr.org/main/python/build-windows-extensions>

I'll check out your link as well as Max's though. I'm not averse to
doing it open source.

Mike

 

[Gabriel Genellina]

...

The package available here:

http://www.develer.com/oss/GccWinBinaries

is quite a lot more straightforward. You do have to be okay with using
GCC 4.1 though. As a bonus, it supports versions of python that link
against several different versions of the Microsoft runtime, rather
than just one.

Thanks! This was the package I were looking for at first, but I could not
find the reference anywhere!

 

[John]

I don't have the answer for this, but I can tell you that I myself
dislike the auto-download behavior and I wish it worked differently.

I've given up on setuptools/easy-install altogether. It is most
annoying to end up with half a dozen unexpected packages.

The default behavior should be to pop a question with a list of
packages that will be downloaded (and have a flag that bypasses this).
And of course being able to turn off this feature from setup.py.

i.

I think you're exactly right, Istvan. Maybe someone will write a patch
for what you suggest.

I haven't done any packaging myself, but it would seem to me that
another trick users could resort to might be to look at the setup.py
setup() function's install_requires arg, and then try to install
what's listed there using their own system's package management
software.

I'm not exactly sure what the --no-deps arg to easy_install does. Does
it force the named package to install without its dependencies, or
does it give a package listing and then bail out without installing
anything? The docs don't seem to specify.

---John