grok

Bug #358719
Comment #13

Comment 13 for bug 358719

Revision history for this message

Ben Dadsetan (bdadsetan) wrote on 2009-04-16:

#13

Hi!

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.

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 :)

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

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. 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

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

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)

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.

Hi!

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 :)

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

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. 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

Just an idea really...

So $${buildout:directory}/parts/etc/zope.conf would become ${target_etc}zope.conf

Disadvantage:
- It looks a little ugly in the template but I think it is acceptable.
- It also requires to pass a raw string

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.