-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Empty build update for testing #1
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
@conda-forge-admin, please rerender |
Hi! This is the friendly automated conda-forge-webservice. I tried to rerender for you, but it looks like there was nothing to do. This message was generated by GitHub actions workflow run https://github.com/conda-forge/pyjulia-feedstock/actions/runs/1838006432. |
Yep, something looks to have changed, I'm getting the following error in the conda-forge build, which didn't happen before.
@mkitti @ngam do you know if something caused this change in the julia-feedstock? |
No idea, but let's try this for now. |
Umm... we did just release 1.7.2 |
If you try locally, for some reason, it cannot compile PyCall correctly... |
|
Indeed it does look like it tried to install 1.7.2. Should I pin to an earlier version?
|
That tells me that we tried to build PyCall.jl before our julia-feedstock activate.sh could setup environmental variables: |
Thanks @MilesCranmer |
should around here usually, |
@mkitti, maybe we have something wrong with the registry?
|
PyCall should be installed by |
@MilesCranmer btw.. you were on to something... julia disappeared from my $CONDA_PREFIX/bin... |
Okay, I think what's going on is that something is erasing the environments. Try it for yourself. I think the error we are gonna get now is "julia cannot be found". Something to do with stacking maybe? I do the following locally: $ mamba create -n pyjl pyjulia
$ mamba activate pyjl
$ mamba list
...
julia 1.7.2
...
$ julia -e 'using Pkg; Pkg.add("PyCall"); Pkg.build("PyCall")'
$ python -c "import julia"
... julia not found ...
$ julia
... no julia ...
$ mamba list
... no julia, no pyjulia |
By environments, do you mean conda environments? |
More loosely, I meant something is erasing the content of the envs. Hence, what happened to @MilesCranmer earlier with julia binary disappearing. Try to reproduce the above steps? |
We might have added this too soon: JuliaPy/Conda.jl#216 was merged, but a new version of Conda.jl has not been released. |
Does PyCall interact with that? |
Yes. PyCall.jl uses Conda.jl to locate Python. Conda.jl may be trying to install it's own conda still. |
I see now... |
🦅 👀 @mkitti, let's revert that CONDA_JL stuff then? |
Check $CONDA_PREFIX before and after? Confirm location of base conda executable. |
@MilesCranmer for future proofing, we may want to always set an upper bound here. What do you think?
|
I think the proper fix would be release a new version of Conda.jl . If that gets stalled for some reason, then perhaps we remove the environmental variables. |
also, let's add a test for @MilesCranmer in our julia build from now on. |
This is the same before and after, fyi |
Introduce CONDA_JL_CONDA_EXE environment variable
But, I am now certain that CONDA_JL is installing its own conda. You can tell by inspection. |
Sounds good. You mean to fix julia version <= 1.7.1 for now right?
Yeah an integration test for PyJulia like this would be smart for the julia feedstock itself. |
Yes, but this wouldn't fix the current builds. We need repopatch for that. Unless 8f71332 gets registered asap, then we don't have to worry about it |
I do have the power to register it, but I should give a chance for the other maintainers to weigh in. |
After running
|
Alright, @MilesCranmer, this should fix it. How long do changes take to take effect in the julia registry? |
Well we need the registry CI to pass first... then it might be an hour to propagate everything through the pkg server mirrors. |
Okay, just asking so that we can retest this PR |
Fantastic, thanks for the quick fixing of this!! Re: registries, it depends on if the julia-feedstock is using the standard registry (up to ~2 hours) or a github-based registry (instant after merging). |
I believe we are using the standard one, so we will revisit in ~2 hours |
We could retest this PR quicker if we put the following in the test steps: rm -rf ~/.julia/registries/General # or wherever the conda one is located
julia -e 'ENV["JULIA_PKG_SERVER"] = ""; import Pkg; Pkg.update()' this will force Pkg to use the GitHub-based registry which is instantly updated after merging |
For the purpose of this test, we could just set JULIA_PKG_SERVER to "" in this pull request. |
Conda.jl 1.7 merged into registry. https://github.com/JuliaRegistries/General/blob/master/C/Conda/Versions.toml#L40-L41 |
What is the registry directory in the conda folder? I'll add it to the test now |
It shouldn't matter since the CI is doing a fresh install. It does not install registry by default until you update. |
phew, it works. |
Amazing. Nice job getting this fix done so quickly! Confirming it works locally too. |
I'm seeing a new issue with PyJulia installs and want to check if the latest conda-forge is failing without changes.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)