Option to allow all environment variables

[raingloom]

First, in light of https://sfconservancy.org/GiveUpGitHub/ I'd like to ask if there is any other way to contribute to the project that is not GitHub?

Second, I'm trying to use Tup on Guix, which takes care of clearing up the environment variables much better than Tup can. It also relies on a lot more variables than Tup seems to anticipate. On Guix, I think it is perfectly safe to assume that the user wants every environment variable to be passed through, and if they want a fully sandboxed deterministic build, they'll just use Guix's tooling, which does a lot more than Tup can on its own.

The problem is, there seem to be no option to just let all variables through. I tried adding one in a fork and I think I finally figured out how to do it, but an "officially sanctioned" way would be nice.

I'd also be fine with it being a hidden option, or something you have to opt into at compile time.

[gittup]

First, in light of https://sfconservancy.org/GiveUpGitHub/ I'd like to ask if there is any other way to contribute to the project that is not GitHub?

Sure, this github repo isn't the "official" upstream repo anyway - I posted it here mostly as a convenience for those people who prefer to use it. You can clone from git://gittup.org/tup.git if you like. You can also post any issues to the tup mailing list, and if you're contributing a patch, feel free to link to your public repo hosted anywhere you choose.

Second, I'm trying to use Tup on Guix, which takes care of clearing up the environment variables much better than Tup can. It also relies on a lot more variables than Tup seems to anticipate. On Guix, I think it is perfectly safe to assume that the user wants every environment variable to be passed through, and if they want a fully sandboxed deterministic build, they'll just use Guix's tooling, which does a lot more than Tup can on its own.

Can you clarify what you mean by clearing the environment much better than tup can? Tup wipes it entirely (except for a few defaults to get standard toolchains working), but if there's a better method I'd like to incorporate it if possible!

Tup would still need to track the environment variables so it can rebuild if necessary. Are there any variables in the Guix environment that would change frequently? If so, the model might need to change from an "(empty environment) + (some variables)" model to a "(full environment) - (some variables)" model for it to work.

The problem is, there seem to be no option to just let all variables through. I tried adding one in a fork and I think I finally figured out how to do it, but an "officially sanctioned" way would be nice.

I'd also be fine with it being a hidden option, or something you have to opt into at compile time.

What do you think about an "export_all" keyword? So instead of having a Tuprules.tup file like:

export VAR1
export VAR2
export ...

You could have:

export_all

Which would go through the tup process' own environment and add all variables.

[raingloom]

gittup @.***> writes:

First, in light of https://sfconservancy.org/GiveUpGitHub/ I'd like to ask if there is any other way to contribute to the project that is not GitHub?

Sure, this github repo isn't the "official" upstream repo anyway - I posted it here mostly as a convenience for those people who prefer to use it. You can clone from git://gittup.org/tup.git if you like. You can also post any issues to the tup mailing list, and if you're contributing a patch, feel free to link to your public repo hosted anywhere you choose.

Oh, didn't realize there was a mailing list. Will use that next time.

Second, I'm trying to use Tup on Guix, which takes care of clearing up the environment variables much better than Tup can. It also relies on a lot more variables than Tup seems to anticipate. On Guix, I think it is perfectly safe to assume that the user wants every environment variable to be passed through, and if they want a fully sandboxed deterministic build, they'll just use Guix's tooling, which does a lot more than Tup can on its own.

Can you clarify what you mean by clearing the environment much better than tup can? Tup wipes it entirely (except for a few defaults to get standard toolchains working), but if there's a better method I'd like to incorporate it if possible!

When used for building packages, Guix tries its best to create a fully reproducible build. I don't know all the details off the top of my head, but it sets up environment variables to only point to actual declared dependencies, resets timestamps, disables network access, etc.

I haven't used tup within a build, only in a development shell, but in a build environment, it would make more sense to let Guix (or Nix) take care of cleaning up. As long as tup doesn't add any nondeterminism, it's fine.

Tup would still need to track the environment variables so it can rebuild if necessary. Are there any variables in the Guix environment that would change frequently? If so, the model might need to change from an "(empty environment) + (some variables)" model to a "(full environment) - (some variables)" model for it to work.

In non-interactive builds they never change. But when an error occurs or when the user is using a development shell (like I was) then they might add new packages by loading them into the environment. Something like this:

source <(guix shell --search-paths gcc-toolchain)

This also happens when a non-interactive build fails but --keep-failed is passed to Guix. In that case, one can cd to the build dir, load the environment variables from a file that Guix leaves there, and try to interactively debug the build, possibly modifying the environment.

In both cases the environment is very unlikely to have anything it in that wasn't put there on purpose, or if there are, a Guix user will likely just use Guix when the package is ready for a proper build.

The problem is, there seem to be no option to just let all variables through. I tried adding one in a fork and I think I finally figured out how to do it, but an "officially sanctioned" way would be nice.

I'd also be fine with it being a hidden option, or something you have to opt into at compile time.

What do you think about an "export_all" keyword? So instead of having a Tuprules.tup file like:

export VAR1 export VAR2 export ...

You could have:

export_all

Which would go through the tup process' own environment and add all variables.

I think offering both options is better. The build might generate a tupfile or something tricky like that. Guix has a concept of build systems, which are basically pre-written recipes for building packages that use a specific build system, so a user does not need to - for example - write all the ./configure and make boilerplate. Guix also passes the necessary flags to build tools. This also makes cross-compiling easier, support for it can be built into the build system support code.

So, for Guix it's very easy to just pass an extra argument tup, or even create a wrapper with the same name that uses the necessary arguments. Patching files is harder.

But when using tup interactively, adding an extra line to the file might be better, because then the user can just copy-paste tup invocations from the docs. Although the user could also just use the wrapped version of tup. This is one reason why Guix is nice, it makes it easy to use custom versions of packages without introducing conflics. UwU

[edwinzrodriguez]

I would like to see a way to specify certain variables that are not checked. i.e. if GCC_COLOR changes that shouldn't trigger a full rebuild.