Revert a revert of a merge that shouldn't have been in master but was intentionally in staging.
Next time I'll do this right after the revert instead of so far down the line...
This reverts commit 9adad8612b.
Newer 'mutagen' versions have a test suite that trips over missing
encoding in this file. The file is copied to source trees at build time
with the name nix_run_setup.py.
Currently, if a user tries to to set a variable that contains
spaces, it will be broken up before being passed to wrapProgram.
This commit resolves that by converting makeWrapperArgs to an
array that preserves any quoted elements using bash's parser.
Fixes#12663: problems in python stuff due to old timestamps in sources.
- Files in sources older than a certain year are set to that year.
- Applied with 1980 for all python packages due to the way it often uses zip.
This reverts commit d34f5b6570.
PIL and NumPy don't like this change and I'd rather spend time on
bringing wheels to Nix than fixing old infrastructure.
Fixes#9044, close#9667. Thanks to @taku0 for suggesting this solution.
Now we have no modes starting with `/` or `+`.
Rewrite the `-perm` parameters of find:
- completely safe: rewrite `/0100` and `+100` to `-0100`,
- slightly semantics-changing: rewrite `+111` to `-0100`.
I cross-verified the `find` manual pages for Linux, Darwin, FreeBSD.
Regression introduced by 5f55788531.
The commit not only changes documentation, but also changed a few
variable names. One of them is $i which now is $f and it contains the
name of the file to wrap.
This was accidentally found by @Profpatsch (thanks!) who found himself
getting the basename of the last patch file to end up in sys.argv[0].
The reason for this is that $i is used in the for loop of the generic
patchPhase and thus is reused later when the Python file is to be
wrapped.
I have also added a small comment noting about this, to be sure that
this won't accidentally occur the next time someone changes variable
names.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should fix#7366 for now, but using the (IMHO) pragmatic approach
of extending the sed expression to recognize strings.
However, this approach is obviously not parsing the full AST, nor does
it wrap Python itself (as pointed out by @spwhitt in #7366) but tries to
match Python strings as best as possible without getting TOO unreadable.
We also use a little bit of Nix to help generating the SED expression,
because doing the whole quote matching block over and over again would
be quite repetitious and error-prone to change. The reason why I'm using
imap here is that we need to have unique labels to avoid jumping into
the wrong branch.
So the new expression is not only able to match continous regions of
triple-quoted strings, but also regions with only one quote character
(even with escaped inner quotes) and empty strings.
However, what it doesn't correctly recognize is something like this:
"string1" "string2" "multi
line
string"
Which is very unlikely that we'll find something like this in the wild.
Of course, we could handle it as well, but it would mean that we need to
substitute the current line into hold space until we're finished parsing
the strings, branch off to another label where we match multiline
strings of all sorts and swap hold/pattern space and finally print the
result. So to summarize: The SED expression would be 3 to 4 times bigger
than now and we gain very little from that.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
