Buildout -- Software for automating application assembly

Buildout chokes on space in directory name

Reported by jhsware on 2007-06-20
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Buildout
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

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.

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

Jason R. Coombs (jaraco) wrote :

Would someone consider applying this patch?

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.

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.

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?

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

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  Edit
Everyone can see this information.

Other bug subscribers