Skip to content
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

OrdinaryDiffEq not dev'able #2378

Open
isaacsas opened this issue Aug 13, 2024 · 5 comments
Open

OrdinaryDiffEq not dev'able #2378

isaacsas opened this issue Aug 13, 2024 · 5 comments
Labels

Comments

@isaacsas
Copy link
Member

(@v1.11) pkg> activate --temp
  Activating new project at `/var/folders/8s/kss4zcyx10v_l22h64zdzs6m0000gn/T/jl_W9Zn0r`

(jl_W9Zn0r) pkg> dev OrdinaryDiffEq
   Resolving package versions...
ERROR: Unsatisfiable requirements detected for package OrdinaryDiffEqQPRK [04162be5]:
 OrdinaryDiffEqQPRK [04162be5] log:
 ├─OrdinaryDiffEqQPRK [04162be5] has no known versions!
 └─restricted to versions * by OrdinaryDiffEq [1dea7af3] — no versions left
   └─OrdinaryDiffEq [1dea7af3] log:
     ├─possible versions are: 6.87.0 or uninstalled
     └─OrdinaryDiffEq [1dea7af3] is fixed to version 6.87.0

(jl_W9Zn0r) pkg> 
@isaacsas isaacsas added the bug label Aug 13, 2024
@isaacsas
Copy link
Member Author

Similar error on 1.10.

@isaacsas isaacsas changed the title OrdinaryDiffEq not dev`able OrdinaryDiffEq not dev'able Aug 13, 2024
@oscardssmith
Copy link
Contributor

the problem is that the master branch depends on all the libraries we have split out, but none of which are registered yet. @ChrisRackauckas I do think we want to think pretty carefully about what our plan for dependency management of the sub-packages is. I think we likely want to lock them all together since they heavily depend on each-others internals, but I'm not sure the optimal way to ensure that works as intended.

@ChrisRackauckas
Copy link
Member

This is already documented: https://github.com/SciML/OrdinaryDiffEq.jl/blob/master/CONTRIBUTING.md#developing-locally.

I do think we want to think pretty carefully about what our plan for dependency management of the sub-packages is. I think we likely want to lock them all together since they heavily depend on each-others internals, but I'm not sure the optimal way to ensure that works as intended.

Indeed it's a bit tricky since we are effectively hitting missing functionality in Julia here.

@oscardssmith
Copy link
Contributor

Should we use the sources section of the Project.toml, which will make it so people on 1.11 at least don't have the problem.

@ChrisRackauckas
Copy link
Member

That's a good idea, I didn't know you could do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants