[issue6884] Impossible to include file in sdist that starts with 'build' on Win32

[Éric Araujo]

Éric Araujo <merwok at netwok.org> added the comment:

Thanks a bunch.  I’ll offer you cookies when we meet :)

>> Fix merged.  I don’t fully understand why one place needs two escapes and the others just one.
> The places that use one level of escaping are the ones that deal with the regex string directly.
> In glob_to_re() itself, the string you're building is a regex replacement pattern that *operates on*
> the regex that gets returned
Makes sense.  I’ve added a comment as you suggested (although an unfunny one, without dragons; I don’t like “you’re not supposed to understand this”-like comments).

>>> I also took the liberty of changing the checks for whether the separator needs to be escaped
>>> - it's better to escape everything except "/", just in case someone decides to port Python to
>>> some platform using a weird directory separator that is neither "/" nor r"\".
>> I didn’t take that part.  If someone wants to port Python with a new style of os.sep or os.extsep,
>> I’ll deal with it when they report that.
> If you want to leave it as it is, that's your choice. But I do think it's better to make this Do The
> Right Thing now, given how easy it is.
I’d be okay with some cleanup in packaging, but for distutils I want the minimal patch.

> Well, as far as I can make out, the current implementation always uses r'\' to join paths. But it
> won't convert existing '/'s in the start path to r'\'s, so you might still end up encountering both
> separators (assuming the initial path is something you get from the user somewhere along the line).
Hm, it should come from the manifest template, i.e. using '/' that get translated to os.sep.  I’ll remove the regex redundancy in packaging, we have rather good tests for manifest and sdist now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________