Comment 14 for bug 358719

Hi Ben,

> I played quite a bit around and as I expected, os.path is of course
> available in python but not generally in our in_tmpl files. These are
> plain text files that are parsed by our software but generally do not
> contain python. Your option 2 would still work though.

I assume you're talking about the Python expression in deploy.conf.in?
Yes, the config files are pure plain text but this specific expression
is evaluated by paster (please do not ask where exactly ;).

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?

> Anyway, before I prepare another patch for testing, I wanted to get
> your thoughts on the following. Let me give you the run-down of your
> alternatives and then let us choose one.
>
> 1) posixish paths all the way (posix_projectdir) Note posix does not
> have the concept of a disk drive (C:). Starting a posix path with a
> 'letter' and ':' makes it very much look like a URL with a strange
> protocol. Or even like ssh/scp host:/path/to/somewhere format.
> Technically this should not matter too much until the day the python
> open() accepts URLs or scp/rcp paths :)

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.

> I have played with this quite a bit and even Windows UNCs work:
> C:/my/path is properly interpreted as C:\my\path
> //mint.blue/share is interpreted as \\mint.blue\share

Nice. Good to know.

> So this works and looks better. It does not follow any standards
> though (no it is not posix).
>
> 2 and 3) These would leave plenty of mixed paths behind, which is quite
> ugly and I thought still is a goal.

Yeah, let's try to use only one path separator.

> I would know how to prepare a patch
> for 2 but not 3.
>
> There is 4 and 5 as well :)
> 4) A new template variable to separate paths (for example: $${os_sep})
> This makes the template files look quite ugly but keeps the python code clean of crazy stuff.
> We would change $${buildout:directory}/parts/etc/zope.conf to $${buildout:directory}$${os_sep}parts$${os_sep}etc$${os_sep}zope.conf

Hm, why not? Note, that in generated templates $${foo} becomes ${foo},
which is better readable. The additional leading '$' quotes the
following '${}' expression, so that buildout does not replace the whole
expression when generating the templates (took me some time to find that
out, therefore I carry this 'hard-earned wisdom' forward here ;).

> Just an idea really...
>
> Finally there is my new favorite option: !!!5!!!
>
> 5) Let us create one
> variable for each target directory (one for parts/etc one for
> parts/log, ...) and let us make this variable's value end with the
> platform specific separator.
>
> So $${buildout:directory}/parts/etc/zope.conf would become
> ${target_etc}zope.conf
>
> Advantages:
> - Uli, you are currently getting feedback on path
> locations. This change would allow us to make a switch to any new
> format by changing only 4 lines in templates.py. - Also it follows
> what the user of a platform knows. So Windows users will see their
> ugly \ and other users will see neat /
>
> Disadvantage:
> - It looks a little ugly in the template but I think it is acceptable.
> - It also requires to pass a raw string

There is another disadvantage, I'm afraid: people that want to use
different paths for generating the config files, could not simply do so.

The target directories are only defaults, changeable by users in
buildout.cfg. One cannot rely on the path names here :(

> I think people really want a new release of grokproject soon. So let us
> choose one of our 5 possibilities. I am happy to supply a patch for
> any of 1, 2, 4, and 5, if it helps you. In any case, I volunteer for
> testing on my 3 platforms (MacOS, Ubuntu, XP)

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.

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?

Before we release we normally had to write an appropriate test for this,
but this will be difficult in this case. We can check the generated
paths but cannot easily do a complete run of the generated project. This
has to be done manually.

> PS: I am happy to contibute to grok even if it is such tiny patches.
> Even if I do not use Windows every day I feel it is important to support
> it well to attract a larger user base.

Most patches are 'tiny', so please don't worry. The larger userbase is
indeed a serious target.