Generate etc/profile/init.sh early #800
Conversation
This should help with debugging failed builds. There is a change in behaviour, though: if we're unpacking a tarball, this means the init.sh from the tarball is used, not the newly-generated one. However, they should be the same. Also, revamp and simplify the code that generates init.sh. Just use a single cat<<\EOF and generate init.sh's code directly from Python, instead of generating shell code that generates init.sh. Also, make init.sh slightly more robust by quoting a few more things where applicable.
| # Set up variables pointing to this package. | ||
| %(package_vars)s | ||
| # Environment variables set by this alidist recipe. | ||
| %(environment)s |
There was a problem hiding this comment.
This might actually be the reason why we did not do this before. Environment variables created by a package should be effective only after the build. Does that change the behaviour?
There was a problem hiding this comment.
No, it doesn't -- this block is inside the heredoc, so it only creates init.sh. It doesn't source it. Further up, only %(source_dependencies)s is executed.
The problem is that the order used to be "unpack tarball" -> "overwrite init.sh" (so the newly-generated init.sh wins); this changes it to "create init.sh" -> "unpack tarball, including init.sh, over the top" (i.e. tarball wins). But as I say in the comment, the files ought to be the same anyway I think...
|
Can we have the revamp and the moving in two separate PRs? Way too many changes. |
This should help with debugging failed builds.
There is a change in behaviour, though: if we're unpacking a tarball, this means the init.sh from the tarball is used, not the newly-generated one. However, they should be the same.
Also, revamp and simplify the code that generates init.sh. Just use a single
cat<<\EOFand generate init.sh's code directly from Python, instead of generating shell code that generates init.sh.Also, make init.sh slightly more robust by quoting a few more things where applicable.