[Distutils] Fwd: Re: Pip 10 is nearing release

[Tim Golden]

On 16/03/2018 09:08, Paul Moore wrote:

After much work, we're pleased to announce that pip 10 is finally
nearing release. We're planning on releasing a beta version over the
weekend of 31 Mar/1 Apr, with the final release to follow about a
fortnight after (assuming no major issues are found).

Hopefully, as many people as possible will be able to test the new
version of pip during the beta period (or before - it's possible to
install pip from github if you don't want to wait!) 

Paul, am I right in thinking that this:

  https://github.com/pypa/pip

is the place to look if we want an advanced preview?

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Fatal error "Python.h"

[Tim Golden]

On 26/06/2017 10:03, Rick wrote:

Hi
Can anyone help?
I’m pretty new to Python and Raspberry Pi.
When running PIP, I seem to get fatal error:

Python.h: No such file or directory

include “Python.h”

compilation terminated

I get this when attempting to download both _Cython_ and _scikit-image_.
 So I’m assuming it is some absent file or path reference on the
Raspberry Pi installation I have, rather than in the distribution package?

What is this file “Python.h” that it is trying to include?


Others have answered the immediate question. But, in general, you'll 
probably want to install tools like Cython and scikit from the Raspberry 
Pi repositories directly (where they come prebuilt).


I don't have an RPi here, but try something like "sudo apt install 
cython scikit"


TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] install_requires setup.py install vs pip install

[Tim Golden]

On 07/03/2017 14:38, Leonardo Rochael Almeida wrote:

Hi Tim,

The reason setuptools can't process your package is because setuptools
itself doesn't yet know how to install wheels[1] which pip knows how to
install, and PyQT5 is only available as wheels on PyPI  (the files with
`.whl` extension in the `simple` URL you linked).

[1] https://github.com/pypa/setuptools/issues/78

The reason why setuptools can install "requests" or "simplejson" is that
their pages contain `.tar.gz` files with the source distributions beside
the `.whl` files.

Incidentally, there are PyQT5 source distributions, and they're
available in their own website[2].

IMO they should be present in PyPI as well.

(Though those archive names with `_gpl` in the middle might confuse
setuptools, and they might prefer to deal with "Could not find suitable
distribution" error message than some obscure compilation error arising
from missing system packages).

[2] https://www.riverbankcomputing.com/software/pyqt/download5/


Thanks, Leo. That was a much simple explanation than I'd been 
considering! I didn't think to look at the output for requests etc. Now 
that I do, it's clearly building eggs from sdists.


Knowing this, I have ways forward. (This is actually about the mu editor 
which is aimed at teachers and other less techie people: 
https://github.com/mu-editor/mu)


Thanks again for your help

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] install_requires setup.py install vs pip install

[Tim Golden]

I have a setup.py which looks like this:

from setuptools import setup
setup(
name='install_requires',
py_modules = ["install_requires"],
install_requires=['PyQt5'],
)

For the purposes of the discussion, there is an install_requires.py in 
the same directory.


I have created and activated a standard Python 3.5 venv on Windows:

py -3.5 -mvenv .venv
.venv\scripts\activate.bat
python -mpip install --upgrade pip

(I don't believe the Python version or the venv matter here, but 
including them for reproducibility).


If I pip install the module, the PyQt5 install dependency is found and 
installed:


(.venv) C:\work-in-progress\install_requires>pip install .
Processing c:\work-in-progress\install_requires
Collecting PyQt5 (from install-requires==0.0.0)
  Using cached PyQt5-5.8.1-5.8.0-cp35.cp36.cp37-none-win_amd64.whl
Collecting sip==4.19 (from PyQt5->install-requires==0.0.0)
  Using cached sip-4.19-cp35-none-win_amd64.whl
Installing collected packages: sip, PyQt5, install-requires
  Running setup.py install for install-requires ... done
Successfully installed PyQt5-5.8.1 install-requires-0.0.0 sip-4.19

If, instead, I setup.py install the module, I get the following messages:

Processing dependencies for install-requires==0.0.0
Searching for PyQt5
Reading https://pypi.python.org/simple/PyQt5/
No local packages or download links found for PyQt5
error: Could not find suitable distribution for Requirement.parse('PyQt5')

However, if I substitute instead "requests" or "simplejson" (both 
well-known packages) then setup.py install succeeds. My cursory 
inspection of https://pypi.python.org/simple/pyqt5/ doesn't reveal 
anything obviously different except for the complexity of the filenames.


I've searched around, including in the archives of this group, but can't 
find that this is a known issue. If I had to guess from the evidence, it 
would be that pip ships a more sophisticated parser of complex wheel 
filenames than setuptools.


Can anyone advise, please?

TJG

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pip install error

[Tim Golden]

On 22/02/2017 18:21, William Gan wrote:

I got your email from the Installing Python Modules page in the Python
3.6.0 documentation.


You might do better ask this kind of question on the Tutor list:

https://mail.python.org/mailman/listinfo/tutor


I encountered an error when trying to install a package in the Python
IDLE shell:


python -m pip install numpy


SyntaxError: invalid syntax


However, the answer here is straightforward enough: the python/pip 
command is an operating system command, ie to be run from the Command 
Prompt, not from the Python prompt.


So:

* Press the Windows Key or otherwise invoke Windows' search mode

* Start typing: cmd

* An icon for the "Command Prompt" should appear. Click it.

* In the window which appears, at the command prompt, type the command 
you used above: python -mpip install numpy


TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Tim Golden]

On 06/11/2015 14:46, Nathaniel Smith wrote:
> On Nov 6, 2015 5:39 AM, "Paul Moore"  > wrote:
>>
>> On 6 November 2015 at 12:10, Donald Stufft  > wrote:
>> > Doesn’t py.exe just look at some ini files and environment variables
> to decide what to invoke? I’m not sure why we couldn’t just replicate
> that behavior. Is there something that py.exe does that we can’t also do
> in Python?
>>
>> What's there might be possible in Python, but there are some nasty
>> special cases. The launcher code looks in the registry, and in order
>> to support running both 32 and 64 bit Pythons from the same launcher
>> exe, it needs to play tricks to see both the 32 and 64 bit registry
>> values, and I'm not sure the APIs to do that are exposed to Python so
>> it may need ctypes.
>>
>> Doable certainly, easy not so sure. We could of course do a simplified
>> version and not try to be precisely equivalent to the launcher
>> behaviour - but that may also cause user confusion. The simplest cases
>> are easy, it's the corner cases that get nasty.
> 
> One option would be to add a "py -which" mode that just does the
> configuration lookup and then prints the path to the real python
> executable. This would add the cost of one subprocess startup per pip,
> but not 6?

FWIW this will do that:

  py -c "import sys; print(sys.executable)"

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Beyond wheels 1.0: helping downstream, FHS and more

[Tim Golden]

On 16/04/2015 08:08, Paul Moore wrote:
> On 16 April 2015 at 00:48, Steve Dower  wrote:
>> On the Start Menu suggestion, I think that's a horrible idea. Pip is not the
>> system package manager and it shouldn't be changing the system. Unversioned
>> script launchers are in the same category, but aren't quite as offensive.
>>
>> I know it's only a hypothetical, but I'd much rather it didn't get repeated
>> so often that it actually happens. There are better tools for making app
>> installers, as opposed to package installers.
> 
> Sorry - I agree it's an awful idea. Older wininst installers such as
> the pywin32 (and I think the PyQT one) one do this, I wanted to use it
> as an example of abuse of postinstall scripts that should *not* be
> perpetuated in any new scheme.

FWIW I've just had a to-and-fro by email with Mark Hammond. I gather
that he's now given Glyph access to the PyPI & hg setup for pywin32.

He's also happy to consider changes to the setup process to support
wheel/virtualenv/postinstall improvements. There's been a side
discussion on the pywin32 list about which versions of Python pywin32
should continue to support going forward, which obviously interacts with
the idea of making it wheel/virtualenv-friendly.

I'm not sure what Glyph's plan is at this point -- doubtless he can
speak for himself. I gather from Paul's comments earlier that he's not a
particular fan of pywin32. If the thing seems to have legs, I'm happy to
coordinate changes to the setup. (I am, technically, a pywin32 committer
although I've never made use of that fact).

The particular issue I'm not sure about is: how does Paul see pywin32's
postinstall steps working when they *are* needed, ie when someone wants
to install pywin32 as a wheel and wants the COM registration to happen?
Or is that a question of: run these steps manually once pip's completed?

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] pywin32 on wheels [was: Beyond wheels 1.0: helping downstream, FHS and more]

[Tim Golden]

[cc-ing Mark H as he indicated he was open to be kept in the loop; also
changed the title to reflect the shift of conversation]

On 16/04/2015 09:21, Paul Moore wrote:
> On 16 April 2015 at 08:30, Tim Golden  wrote:
>>> Sorry - I agree it's an awful idea. Older wininst installers such as
>>> the pywin32 (and I think the PyQT one) one do this, I wanted to use it
>>> as an example of abuse of postinstall scripts that should *not* be
>>> perpetuated in any new scheme.
>>
>> FWIW I've just had a to-and-fro by email with Mark Hammond. I gather
>> that he's now given Glyph access to the PyPI & hg setup for pywin32.
>>
>> He's also happy to consider changes to the setup process to support
>> wheel/virtualenv/postinstall improvements. There's been a side
>> discussion on the pywin32 list about which versions of Python pywin32
>> should continue to support going forward, which obviously interacts with
>> the idea of making it wheel/virtualenv-friendly.
> 
> Thanks for involving Mark in this. While pywin32 isn't the only
> project with a postinstall script, it's one of the most complex that I
> know of, and a good example to work from when looking at what projects
> need.
> 
>> I'm not sure what Glyph's plan is at this point -- doubtless he can
>> speak for himself. I gather from Paul's comments earlier that he's not a
>> particular fan of pywin32. If the thing seems to have legs, I'm happy to
>> coordinate changes to the setup. (I am, technically, a pywin32 committer
>> although I've never made use of that fact).
> 
> To be clear, I don't have that much of a problem with pywin32. I don't
> use it myself, these days, but that's because (a) it's a very big,
> monolithic dependency, and (b) it's not usable directly with pip. The
> problem I have with it is that a lot of projects use it for simple
> access to the Win32 API (uses which can easily be handled by ctypes,
> possibly with slightly more messy code) and that means that they
> inherit the pywin32 problems. So I advise against pywin32 because of
> that, *not* because I think it's a problem itself, when used for
> situations where there isn't a better alternative.
> 
>> The particular issue I'm not sure about is: how does Paul see pywin32's
>> postinstall steps working when they *are* needed, ie when someone wants
>> to install pywin32 as a wheel and wants the COM registration to happen?
>> Or is that a question of: run these steps manually once pip's completed?
> 
> To be honest, for the cases I encounter frequently, these requirements
> don't come up. So my experience here goes back to the days when I used
> pywin32 to write COM servers and services, which was quite a while
> ago.
> 
> From what I recall, pywin32 has the following steps in its postinstall:
> 
> 1. Create start menu entries. My view is that this should simply be
> dropped. Python packages should never be adding start menu entries.
> Steve Dower has confirmed he agrees with this view earlier on this
> thread.
> 2. Move the pywin32 DLLs to the system directory. I don't see any way
> this is compatible with per-user or virtualenv installs, so I don't
> know how to address this, other than again dropping the step. I've no
> idea why this is necessary, or precisely which parts of pywin32
> require it (I've a recollection from a long time ago that "services
> written in Python" was the explanation, but that's all I know). But
> presumably such use cases already break with a per-user Python
> install?
> 3. Registering the ActiveX COM DLLs. I believe this is mostly obsolete
> technology these days (who still uses ActiveX Scripting in anything
> other than VBScript or maybe a bit of JScript?) I'd drop this and make
> it a step that the user has to do manually if they want it. In place
> of it, pywin32 could provide an entry point to register the DLLs
> ("python -m pywin32 --register-dlls" or something). Presumably users
> who need it would understand the implications, and how to avoid
> registering multiple environments or forgetting to unregister before
> dropping an environment, etc. That sort of pitfall isn't something
> Python should try to solve automatically via pre- and post- install
> scripts.
> 4. Registering help files. I never understood how that worked or why
> it was needed. So again, I'd say just drop it.

Really, pywin32 is several things: a set of libraries (win32api,
win32file, etc.); some system-level support for various things (COM
registration, Service support etc.); and a development/editing
environment (

Re: [Distutils] Call for information - What assumptions can I make about Unix users' access to Windows?

[Tim Golden]

On 09/11/2014 12:13, Vinay Sajip wrote:

Thanks, that's very useful feedback. I agree, the need for RDP is
very



Windows-specific - I don't know how common RDP tools are for Unix,
but





Not uncommon, AFAIK. For example, I use rdesktop on Lubuntu to access
Windows machines via RDP, and it seems fairly stable. There are
alternative tools available (such as remmina).


I think the OP was speaking not so much about having the technical 
wherewithal to use RDP but rather about the experience of RDP vs SSH. 
The difficulty is that Windows doesn't really "think" in ssh. I believe 
there are (third-party) mechanisms to provide ssh-like access, but I 
don't know how successful they really are.


TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Test Windows Installers

[Tim Golden]

On 03/10/2013 15:20, Tim Golden wrote:
> They all install and appear to have dropped the right files in the right
> place. Haven't actually tried installing anything yet!

Sorry... that obviously got caught in moderation; I sent it a day ago.
Fairly useless now given Steve's extensive testing & analysis!

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Test Windows Installers

[Tim Golden]

On 03/10/2013 15:11, Donald Stufft wrote:
> Anyone who has a windows machine mind testing some installers for me?
> 
> These should install pip and setuptools:
> 
> https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py27.msi
> 
> https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py32.msi
> 
> https://dl.dropboxusercontent.com/u/45265381/MSI/pip/1.4/pip-1.4-py33.msi

They all install and appear to have dropped the right files in the right
place. Haven't actually tried installing anything yet!

TJG

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Replacing pip.exe with a Python script

[Tim Golden]

On 17/07/2013 20:12, Paul Moore wrote:

On 17 July 2013 19:55, Steve Dower  wrote:


I'm afraid exe files as wrappers are probably the only viable option.

The basic

reason is that the OS recognises exe files in all context, with no

special

configuration needed. This is not true of any other file type. So

anything else

will have corner cases that will give unexpected results.


No reason to be afraid of this, exe wrappers are totally the best option.

As for updating .exes while they're running, the best approach is to
rename the running one (e.g. 'pip.exe' -> 'pip.exe.deleteme') in the same
folder and either:
* delete any existing .deleteme files on next run, or
* delete an existing pip.exe.deleteme file immediately before trying to
rename to it

Any other approach will also have corner cases, but this will be the most
reliable in the context of multiple users/permissions/environment variables.


The problem issue remaining is recognising when we need to do this. In
terms of code paths, pip install -U pip is no different from (for example)
pip install -U flask. But it needs to be handled specially just because
it's pip.


I don't think it does: in essence, any distribution which installs an 
.exe wrapper for some entry point can (possibly should) be treated the 
same way. Assuming that flask installed some kind of "run-flask.exe" in 
scripts/ you'd do the same thing: rename in-place so that the old one 
could keep running; write the new one under the old name; delete the old 
one (if you can).


The issue of deleting the .deleteme versions of arbitrary scripts is 
that you don't know when they might be delete-able. In the Flask 
example, assume that someone was actually using run-flask.exe to run a 
Flask app, you can rename the .exe but you won't be able to delete it 
until it had finished running. Unless you have a watchdog script which 
watches the file / folder then you just have to call it .deleteme and 
clean up as best you can the next time round.


TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] py2exe - COM Server DLL can't be referenced by VB6 or VS2003

[Tim Golden]

J.D. Main wrote:

Thanks. I didn't know about that one.  It's not listed on the Python SIG page:

http://www.python.org/community/sigs/current/


Interestingly, I've never even thought of looking at
that page, and probably wouldn't have considered
win32 as a SIG -- even though it arguably is :)

For a wide range of Python mailing lists, look here:

 http://mail.python.org

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] py2exe - COM Server DLL can't be referenced by VB6 or VS2003

[Tim Golden]

J.D. Main wrote:

Hey Guys,

I guess nobody knows or cares.  Where do the Win32 python guys hang 
out?



Try the python-win32 list:

http://mail.python.org/mailman/listinfo/python-win32

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Distutils functionality questions/clarifications...

[Tim Golden]

Tim Golden wrote:

svn co https://pythonpkgmgr.svn.sourceforge.net/svnroot/pythonpkgmgr
pythonpkgmgr


I'll give that a try.



Not that I think it's necessarily the issue, but you've got mixed
tabs and spaces in there, which is never a good recipe. I tried
translating using 4 but didn't seem to work. Probably worth
sorting that out...

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Distutils functionality questions/clarifications...

[Tim Golden]

David Lyon wrote:

On Wed, 03 Jun 2009 16:25:08 +0100, Tim Golden 
wrote:

C:\Program Files\Python Package Manager>dir /b
gdiplus.dll
msvcp71.dll
MSVCR71.dll
pkgmgr
PythonPackageManager.exe
PythonPackageManager.exe.log
uninstall.exe



FWIW, the "C:\Program Files\Python Package Manager" directory
it installed into looks very empty:
"""

Maybe something's up with your installer setup?


That looks correct there aren't many files...




Perphaps you are using vista...


Nope. XP SP3



The code is breaking where it is looking in the registry to
see what versions of python are installed on your machine.


(Which is several; I've got 2.3 to 2.7 in the registry)


I do accept the code is somewhat fragile at this point in
time. I'm only testing on 2.2, 2.5, 2.6 under windows 2000,
xp, and ubuntu at the moment.



svn co https://pythonpkgmgr.svn.sourceforge.net/svnroot/pythonpkgmgr
pythonpkgmgr


I'll give that a try.


TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Distutils functionality questions/clarifications...

[Tim Golden]

David Lyon wrote:

On Wed, 03 Jun 2009 16:11:45 +0100, Tim Golden 
wrote:

Traceback (most recent call last):
  File "PythonPackageManager.py", line 22, in 
  File "PythonPackageManager.py", line 18, in main
  File "wx\_core.pyc", line 7938, in __init__
  File "wx\_core.pyc", line 7512, in _BootstrapApp
  File "PythonPackageManager.py", line 12, in OnInit
  File "MainWindow.pyc", line 29, in create
  File "MainWindow.pyc", line 374, in __init__
  File "Packaging.pyc", line 94, in __init__
  File "Packaging.pyc", line 600, in setworkingversion
  File "Packaging.pyc", line 686, in pythonversonlist
WindowsError: [Error 2] The system cannot find the file specified

"""


Thanks for testing it so quickly and reporting...

I'll post it as a bug report...

and look into it as soon as I am able...

David


FWIW, the "C:\Program Files\Python Package Manager" directory
it installed into looks very empty:

"""
C:\Program Files\Python Package Manager>dir /b
gdiplus.dll
msvcp71.dll
MSVCR71.dll
pkgmgr
PythonPackageManager.exe
PythonPackageManager.exe.log
uninstall.exe
"""

Maybe something's up with your installer setup?

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Distutils functionality questions/clarifications...

[Tim Golden]

David Lyon wrote:

On Wed, 3 Jun 2009 10:33:46 +0100, Paul Moore  wrote:


*If* there was an existing "python package manager", it is possible
that it would provide compelling enough features to convince me to
change my mind. Build it and I'll tell you. Hey, build even some of it
and I'll comment on what you have 


ok - that's fair enough... done

Just follow the download link...

http://sourceforge.net/projects/pythonpkgmgr/


"""
Traceback (most recent call last):
 File "PythonPackageManager.py", line 22, in 
 File "PythonPackageManager.py", line 18, in main
 File "wx\_core.pyc", line 7938, in __init__
 File "wx\_core.pyc", line 7512, in _BootstrapApp
 File "PythonPackageManager.py", line 12, in OnInit
 File "MainWindow.pyc", line 29, in create
 File "MainWindow.pyc", line 374, in __init__
 File "Packaging.pyc", line 94, in __init__
 File "Packaging.pyc", line 600, in setworkingversion
 File "Packaging.pyc", line 686, in pythonversonlist
WindowsError: [Error 2] The system cannot find the file specified

"""


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Changes in r72585

[Tim Golden]

Tarek Ziadé wrote:

Thanks. Happy to run it through my "buildman" to check it
covers that case.


Done in r72781, and currently propagating it to the branches

Thanks for the feedback Tim !


Thanks for the swift response. I'll try a rebuild against
trunk and release26 at least.

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Changes in r72585

[Tim Golden]

Tarek Ziadé wrote:

On Tue, May 19, 2009 at 5:01 PM, Tim Golden  wrote:


Index: Lib/distutils/command/build_ext.py
===
--- Lib/distutils/command/build_ext.py  (revision 72780)
+++ Lib/distutils/command/build_ext.py  (working copy)
@@ -652,7 +652,8 @@
filename = self.get_ext_filename(ext_name)
return os.path.join(package_dir, filename)
else:
-filename = self.get_ext_filename(ext_name)
+fullname = self.get_ext_fullname(ext_name)
+filename = self.get_ext_filename(fullname)
return os.path.join(self.build_lib, filename)

def get_ext_fullname(self, ext_name):



Ok I see what's wrong. I am writing a test + fix right away.

build_ext and all the compiling code is still really undertested in
Distutils. I've kinda opened a can of worms
since I am working on the compilers part of the package.

I'll let you know when it's fixed.


Thanks. Happy to run it through my "buildman" to check it
covers that case.

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Changes in r72585

[Tim Golden]

Tarek Ziadé wrote:

By the way,

Do you happen to have a pywin32 buildbot that could run on the python
trunk ? (where I can get emails when it's broken)


I have what you might call a manual buildbot. (A buildman?)
I have set up an environment where I can create
installers for python trunk & pywin32 for the trunk
and principal branches (release-maint26 / py3k).

Once I've ironed out the issues with those, I hope
to be able to do the same for other simple projects
such as pyodbc which don't require large amounts of
library configuration.

Ultimately, I hope to be able to link into something
like snakebite.org to produce overnight build MSIs
of Windows projects. (Long-term plan, tho'!)

TJG



That would be useful because I am doing a lot of work in the trunk.

Tarek


On Tue, May 19, 2009 at 4:54 PM, Tarek Ziadé  wrote:

Hi Tim, thanks for the feedback,

this has been fixed in r72758

http://svn.python.org/view/python/trunk/Lib/distutils/command/build_ext.py?r1=72593&r2=72758

Regards
Tarek

On Tue, May 19, 2009 at 4:00 PM, Tim Golden  wrote:

[coming from a thread on python-win32:
http://mail.python.org/pipermail/python-win32/2009-May/009130.html
]

In short: changes to build_ext.py in r72585 caused the pywin32
packages to stop building correctly. The changes in question
are those which call get_ext_filename with the short form of
the ext.name (without the package prefix). The pywin32 setup.py
expects the fully-qualified name in the get_ext_filename in
its subclass.

Now I don't know whether this is an incautious change to build_ext
or a false -- altho' historically valid -- assumption on the part
of the pywin32 developers. You can see their code here at line 1119:

http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/setup.py?revision=1.107&view=markup

I'm afraid I'm fairly ignorant of the design rationale behind
distutils; I'm hoping someone here has a better idea :)

Opinions?

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig




--
Tarek Ziadé | http://ziade.org







___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Changes in r72585

[Tim Golden]

Tarek Ziadé wrote:

Hi Tim, thanks for the feedback,

this has been fixed in r72758

http://svn.python.org/view/python/trunk/Lib/distutils/command/build_ext.py?r1=72593&r2=72758


'fraid not :)

It was running against r72758 which showed the bug up:
I had to back-track through a few revisions to find what
introduced it.

The attached patch against r72780 "fixes" the problem
(ie makes pywin32 build correctly) but since I've no
real idea what the intention of the code is, I've likewise
no idea of what I might be breaking by doing this :(

TJG
Index: Lib/distutils/command/build_ext.py
===
--- Lib/distutils/command/build_ext.py  (revision 72780)
+++ Lib/distutils/command/build_ext.py  (working copy)
@@ -652,7 +652,8 @@
 filename = self.get_ext_filename(ext_name)
 return os.path.join(package_dir, filename)
 else:
-filename = self.get_ext_filename(ext_name)
+fullname = self.get_ext_fullname(ext_name)
+filename = self.get_ext_filename(fullname)
 return os.path.join(self.build_lib, filename)
 
 def get_ext_fullname(self, ext_name):
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Changes in r72585

[Tim Golden]

[coming from a thread on python-win32:
http://mail.python.org/pipermail/python-win32/2009-May/009130.html
]

In short: changes to build_ext.py in r72585 caused the pywin32
packages to stop building correctly. The changes in question
are those which call get_ext_filename with the short form of
the ext.name (without the package prefix). The pywin32 setup.py
expects the fully-qualified name in the get_ext_filename in
its subclass.

Now I don't know whether this is an incautious change to build_ext
or a false -- altho' historically valid -- assumption on the part
of the pywin32 developers. You can see their code here at line 1119:

http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/setup.py?revision=1.107&view=markup

I'm afraid I'm fairly ignorant of the design rationale behind
distutils; I'm hoping someone here has a better idea :)

Opinions?

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Tim Golden]

Bob Kline wrote:
> Are things really that different in the non-Windows worlds?  If I want 
> python-nose, I run "sudo apt-get install python-nose" (and that means I 
> can always remove it with "sudo apt-get remove ...").  Seems more 
> similar than different (ignoring the silliness of Microsoft's insistence 
> on "the GUI is the OOWTDI" even for such administrative tasks as 
> installing system-wide software).

I was going to -- pointedly -- drop in here the help output
for msiexec, which is the commandline version of the MSI
installation graphical stuff. Only... when I did msiexec /?,
the result was that a Window popped up with the information
in it. (Sort of agrees with your point a bit!)

Still, here's the info (cut-and-pasted from that window):

-

Windows ® Installer. V 3.01.4000.1823

msiexec /Option  [Optional Parameter]

Install Options
 
Installs or configures a product
/a 
Administrative install - Installs a product on the network
/j  [/t ] [/g ]
Advertises a product - m to all users, u to current user
 
Uninstalls the product


[... snip lots of other options ...]

TJG
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig