Comment 15 for bug 358719

Revision history for this message
Ben Dadsetan (bdadsetan) wrote : Re: [Bug 358719] Re: backslashes in windows paths should be doubled

Hi,

[snip]
> I checked on Ubuntu, where::
>
> args = (os.path.join(r'${buildout:directory}', 'parts', 'log', \
>        'access.log'), 'a')
>
> is interpreted correctly. Looks like the `os` module is available when
> the expression gets evaluated.
>
> Can you confirm that behaviour for Windows too?

I checked. It works fine.
args = (os.path.join(r'$${buildout:directory}','parts','log','access.log'),'a')
   translates to:
args = (os.path.join(r'C:\grok\abart','parts','log','access.log'),'a')

[snip]
> Right. To be more standard-conform, one could use the urlparse functions
> from urllib/urllib2. But this (generates URLs like 'file:///foo/bar')
> would not be accepted by regular `open()` I think.

Correct, it would not be accepted and I think it is way overkill a
reengineering. If we do get the usecase sometime we might want to do
it but being able to manage writes to any URL is quite a task :)

[snip]
> Yes, we must release soon, as currently grokproject generates broken
> projects.
>
> Therefore I am currently tending to opt for one of your first patches
> (passing ${buildout:directory} as raw string), maybe enriched with
> `os.path.join()` if that works on Windows.

I have tested this as I explained above and it works. For now let us
go for this. We will have mixed paths but it will allow us to build
projects with grokproject again. By the way, the little experience I
had with Cygwin (somewhat unrelated but still has path experiece in
windows world) showed there is often mixed paths on such systems. With
pure shell scripts it can even break things. But as the CPython
interpreter for Windows accept it I feel we can live with it for now.

>
> This is a change which is good to handle. Could you anyway give a list
> of other paths generated on Windows in the different config files? What
> for instance becomes of the %(here)s/zope.conf expression in
> deploy.ini.in? What looks the `site-definition` on top of zope.conf
> looks like in generated zope.conf? Do you get a better formed path when
> in zope.conf.in you replace::
>
>    path ${buildout:directory}/parts/data/Data.fs
>
> (in the zodb/filestorage section) with::
>
>    path ${data:path}
>
> and rerun buildout on Windows?

path ${data:path} becomes a neat:
path C:\grok\adart\parts\data\Data.fs