Setting environment variables of tools used during build to lead to the
binaries in nix-store.
This way, we can remove some checks for PHOENIX_NIX in the build
scripts.
Skipping uv for now, as I don't think we will use it on nix. Just as we
didn't use pyenv.
nix: set PHOENIX_* of build tools to bins in nix-store #337
If you don't mind it would be great to backport this to the pages branch as well, so the new release for nix users isn't broken until the next one lands. (Same for dove)
actually closes #335 i guess...
this seems like the proper fix for nix, why not also set all the other PHOENIX_* tools this way?
does /bin/date (PHOENIX_DATE) work?
@degausser wrote in #337 (comment):
this seems like the proper fix for nix, why not also set all the other PHOENIX_* tools this way? does
/bin/date(PHOENIX_DATE) work?
You are right, we should probably do that. E.g. to not break the nix build when another default changes. I will take a look and add them.
856dacb4be
to 309b5088f9
@ddogfoodd wrote in #337 (comment):
@degausser wrote in #337 (comment):
this seems like the proper fix for nix, why not also set all the other PHOENIX_* tools this way? does
/bin/date(PHOENIX_DATE) work?You are right, we should probably do that. E.g. to not break the nix build when another default changes. I will take a look and add them.
Yeah, I agree this would be ideal - so do you think we should wait to merge this until we update those other defaults as well, or should I go ahead and merge this now? (And yeah don't worry, I'll backport this fix to pages).
PS - Thanks for the PR here!
@celenity wrote in #337 (comment):
Yeah, I agree this would be ideal - so do you think we should wait to merge this until we update those other defaults as well, or should I go ahead and merge this now? (And yeah don't worry, I'll backport this fix to
pages).
Just pushed and tested. Feel free to merge. Will do Dove later.
@ -5,1 +5,4 @@
coreutils, # to provide `date`
gnused,
gnutar,
zip,
Also wondering if we still need zip here? I assume this was added because we used to create ZIP archives for all build outputs (regardless of platform), but nowadays we only create ZIP archives for Windows builds - OS X and Linux should always be creating/using tar.xz archives instead.
@ -5,1 +7,4 @@
gnutar,
zip,
python3,
s3cmd,
Do we really need to include s3cmd here? It's only used for pushing releases to S3 storage (ex. for CI) - it shouldn't be necessary/used at all for building Phoenix directly.
9ebbbec97f should be reverted when this lands.
also this seems useless, since the pref isn't included in the config anyways.
pro futuro,
I'll also note that it's possible use your own Python/system Python if preferred, instead of downloading it from get_sources.sh, by setting PHOENIX_PYTHON to point to your desired location of Python, and by creating your own virtual environment + setting PHOENIX_PYENV_DIR to the path of that environment (I would definitely like to document this though, as well as the other variables).
should be applied to the nix build process, which would make s3cmd, awk (PHOENIX_AWK is only used in get_sources_phoenix.sh) unnecessary. since it uses the output files directly, zip, tar (& date) shouldn't be needed too (fly.sh needs a flag/envvar to not create the archives), so only sed.
You are right, I just added every PHOENIX_* I saw in fly.sh, removing. What about awk and date? Since the build didn't fail without replacing their bin paths...
Sed did work before because it was set to just sed on Nix.
@degausser wrote in #337 (comment):
should be applied to the nix build process, which would make s3cmd, awk (PHOENIX_AWK is only used in get_sources_phoenix.sh) unnecessary. since it uses the output files directly, zip, tar (& date) shouldn't be needed too (fly.sh needs a flag/envvar to not create the archives), so only sed.
So don't call the create_archive function when PHOENIX_NIX is set or are there further conditions in which not to create an archive?
@ddogfoodd wrote in #337 (comment):
What about awk and date? Since the build didn't fail without replacing their bin paths...
IMO we should probably keep awk and date, because they are used directly by the build scripts (which could impact Nix) - ex. date is used for producing the output archives and awk is used for parsing inputs for some of the scripts (I don't think it's technically used directly by fly.sh at the moment though, but it could/will likely be in the future).
@ddogfoodd wrote in #337 (comment):
So don't call the
create_archivefunction when PHOENIX_NIX is set or are there further conditions in which not to create an archive?
No, create_archive is actually always called ATM - that being said, I do need to/intend to add an env variable to support disabling it. Once we add it, we can probably set it to the default for Nix builds, and then at that point, we can safely remove date - but we probably need to keep it for now since we don't yet have a mechanism to disable it.
309b5088f9
to 199530327f
@degausser wrote in #337 (comment):
9ebbbec97fshould be reverted when this lands.
Yeah, it looks like the changes here should revert that.
also this seems useless, since the pref isn't included in the config anyways.
Agreed - I'm honestly not sure why it was ever added in the first place - guessing it was just something that got added a long time ago. Good catch!
LGTM, thank you both for your efforts @ddogfoodd @degausser!! ❤️
Thank you all too!
FYI: I just went ahead and added support for the env variable to disable archive creation (defaults to disabled for Nix) - ff537c0f75 - I also went ahead and removed the dependency on date for Nix, since we'll no longer need it for future releases.
@celenity wrote in #337 (comment):
FYI: I just went ahead and added support for the env variable to disable archive creation (defaults to disabled for Nix) -
ff537c0f75- I also went ahead and removed the dependency ondatefor Nix, since we'll no longer need it for future releases.
Occurred to me we should no longer need GNU tar as well, so I went ahead and removed that too.
@celenity TZ manipulation should depend on PHOENIX_PRODUCE_ARCHIVES, since it's relevant only for date; just touch-ing the output files is meaningless for "reproducibility"
also we can ducttape the current scripts all we want, but it's obvious fly.sh should be callable on its own, without get_sources{,_phoenix}.sh via build.sh, which would alleviate a lot of related packaging problems (see the debian issue)
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?