setuptools without unexpected downloads

Steve Holden steve at
Thu Sep 27 17:34:12 CEST 2007

kyosohma at wrote:
> On Sep 26, 5:52 pm, Steve Holden <st... at> wrote:
>> kyoso... at wrote:
>>> On Sep 26, 8:30 am, Steve Holden <st... at> wrote:
>>>> Fredrik Lundh wrote:
>>>>> Paul Boddie wrote:
>>>>>> P.S. Of course, the package maintainer problem manifests itself most
>>>>>> prominently on Windows where you often see people asking for pre-built
>>>>>> packages or installers.
>>>>> for the record, I'd love to see a group of volunteers doing stuff like
>>>>> this for Windows.  there are plenty of volunteers that cover all major
>>>>> Linux/*BSD distributions (tons of thanks to everyone involved in this!),
>>>>> but as far as I can remember, nobody has ever volunteered to do the same
>>>>> for Windows.
>>>> I'd like to see something like this happen, too, and if a group of
>>>> volunteers emerges I'll do what I can through the PSF to provide
>>>> resources. Activities that benefit the whole community (or a large part
>>>> of it) are, IMHO, well worth supporting.
>>> 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
>>> that's all it is, I would think it would be fairly easy to create
>>> these. Maybe I'm over-simplifying it though.
>>> What are a some examples of packages that need this?
>> 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
>> Skype: holdenweb
>> 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.

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 ...

Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd 
Skype: holdenweb

Sorry, the dog ate my .sigline

More information about the Python-list mailing list