Buildout chokes on space in directory name

Bug #121325 reported by jhsware
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Buildout
New
Undecided
Unassigned

Bug Description

If I have a "space" in a directory name and do a buildout installing Zope3. It will choke with:

SystemError:
('Failed', './configure --prefix=/Users/sebastianware/Grok Projects/Grokstar/parts/zope3 --with-python=/usr/local/bin/python2.4 --force')

I am guessing one should add double quotes at the appropriate places. So it looks like:
./configure --prefix="/Users/sebastianware/Grok Projects/Grokstar/parts/zope3" --with-python="/usr/local/bin/python2.4" --force

Revision history for this message
Philipp von Weitershausen (philikon) wrote :

This issue is about the old pre-eggs buildout that grokproject generated. However, the issue is still valid, because if your Python executable is located in a directory with spaces (e.g. C:\Program Files\Python24\python.exe), the generated scripts won't work because they're lacking double quotes.

This is really a buildout issue, so I'm changing the affected project to that.

Revision history for this message
Jason R. Coombs (jaraco) wrote :

This past Plone sprint I put together a patch that addresses the spaces in the python path issue. It's been tested on a Windows box using ZopeSkel.

This patch does the following things:

move jython support code into its own module
instead of os.popen, use subprocess, which has better platform-independent path handling.
_safe_arg is no longer needed, but kept for backward compatibility

Revision history for this message
Jason R. Coombs (jaraco) wrote :

Would someone consider applying this patch?

Revision history for this message
Jason R. Coombs (jaraco) wrote :

I see that r96392 in the trunk addresses the underlying issue for which this patch was developed.

Nevertheless, a good deal of effort was put into this patch to unify and clarify the code. If Python 2.4 can be assumed for zc.buildout, then this patch should make the code easier to read and maintain.

Please someone consider applying this patch or otherwise tell me that I should stop caring.

I'm attaching a new version of the patch that applies to the trunk. Basically, in addition to the previously-contributed changes, it reverts the change in r96392 which was rendered unnecessary with this patch.

I would be happy to perform tests or otherwise do whatever is necessary to get this patch applied.

Please advise.

Revision history for this message
Reinout van Rees (reinout) wrote :

The 1.1.2, released today, mentions that spaces in paths are handled fine now (it especially mentions windows). I don't know if your patch was used for that, but you could check if it fixes your issue.

Revision history for this message
Jason R. Coombs (jaraco) wrote :

I acknowledge that r96392 does address the issue.

However, the attached patch goes much farther in creating less complicated code.

What would it take to get feedback from the community? Now that 1.1.2 has been released, can this patch be applied to the trunk in order to get community feedback?

Revision history for this message
Jim Fulton (jim-zope) wrote : Re: [Bug 121325] Re: Buildout chokes on space in directory name

Did you also look at r97510?

Jim

On Mar 17, 2009, at 4:56 PM, Jason R. Coombs wrote:

> I acknowledge that r96392 does address the issue.
>
> However, the attached patch goes much farther in creating less
> complicated code.
>
> What would it take to get feedback from the community? Now that 1.1.2
> has been released, can this patch be applied to the trunk in order to
> get community feedback?
>
> --
> Buildout chokes on space in directory name
> https://bugs.launchpad.net/bugs/121325
> You received this bug notification because you are a direct subscriber
> of the bug.

--
Jim Fulton
Zope Corporation

Revision history for this message
Jason R. Coombs (jaraco) wrote :

I had not seen r97510.

r97510 takes another baby step toward the work I put together last October. It converts one call of os.popen4 to subprocess.Popen.

There are still several calls within easy_install that call subprocesses. All of these use if/else and handle the results somewhat differently depending on if jython is present or not. Also, windows arguments are handled in an ad-hoc manner, requiring every instance of an argument to be properly wrapped by the _safe_arg call.

My patch eliminates the need for the _safe_arg function, although it's kept for compatibility in case other dependent projects use it. It also factors the jython-specific code into its own module for clear designation. This eliminates a lot of duplicate code and makes the module somewhat easier to read. There are fewer branches and more unified handling.

I've merged the patch once again against the trunk. I hope this new revision will be considered for inclusion.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.