1

I’m trying to install the ASE package and getting this error message:

(@v1.11) pkg> add ASE
   Resolving package versions...
ERROR: Unsatisfiable requirements detected for package Dierckx [39dd38d3]:
 Dierckx [39dd38d3] log:
 ├─possible versions are: 0.4.0 - 0.5.4 or uninstalled
 ├─restricted by compatibility requirements with JuLIP [945c410c] to versions: 0.4.0 - 0.4.2
 │ └─JuLIP [945c410c] log:
 │   ├─possible versions are: 0.6.0 - 0.8.2 or uninstalled
 └─restricted by compatibility requirements with BinaryProvider [b99e7846] to versions: 0.5.0 - 0.5.4 or uninstalled — no versions left
   └─BinaryProvider [b99e7846] log:
     ├─possible versions are: 0.4.0 - 0.5.10 or uninstalled
     └─restricted by julia compatibility requirements to versions: uninstalled

Is this telling me that ASE is not compatible with my current version of julia? I noticed it hasn’t been worked on for 5-6 years.

2

Didn’t look into it deeply, but from the output you gave I see ASE.jl depends on Dierckx.jl, and it seems like there are conflicting requirements on what version of Dierckx.jl is required. Keep in mind Julia’s package manager only allows a single version of a package in a single environment. So if A depends on B@1, but C depends on B@2, you can’t have both A and C in the same environment.

In summary, I don’t think this is about the version of Julia. You might have better luck by trying to install ASE.jl in an empty enviroment/project (TBH I can’t remember the difference between an environment and a project, if any).

TBH, that usually means the package is not worth depending on unless you’re willing to take up maintaining it.

2 Likes
3

That was my thought exactly…

1 Like
4

What’s your environment’s ]st?

5 
(@v1.11) pkg> st
Status `~/.julia/environments/v1.11/Project.toml`
  [a963bdd2] AtomsBase v0.5.1
  [6e4b80f9] BenchmarkTools v1.6.0
  [861a8166] Combinatorics v1.0.3
  [39dd38d3] Dierckx v0.5.4
⌃ [31c24e10] Distributions v0.25.115
⌃ [7073ff75] IJulia v1.26.0
  [b964fa9f] LaTeXStrings v1.4.0
⌃ [b4f0291d] LazySets v4.0.0
  [3db4a2ba] LegendrePolynomials v0.4.5
  [442fdcdd] Measures v0.3.2
  [7b2266bf] PeriodicTable v1.2.1
⌃ [91a5bcdd] Plots v1.40.9
  [a8468747] QHull v0.2.6
⌃ [295af30f] Revise v3.6.4
  [f761d5c5] Spglib v0.9.5
  [90137ffa] StaticArrays v1.9.13
⌃ [2913bbd2] StatsBase v0.34.3
⌃ [0c5d862f] Symbolics v5.16.1
  [a759f4b9] TimerOutputs v0.5.29
  [1986cc42] Unitful v1.22.1
  [a7773ee8] UnitfulAtomic v1.0.0
⌃ [ddb6d928] YAML v0.4.12
  [37e2e46d] LinearAlgebra v1.11.0
Info Packages marked with ⌃ have new versions available and may be upgradable.
6

Not seeing anything stand out there. Dierckx v0.5.4 is there, but by default that version is allowed to change to let the environment resolve. Looking at the Dierckx repo, v0.4 depends on BinaryProvider v[0.5.3, 0.6) (archived, btw, so more obsolete than just inactive), while v0.5 began depending on a series of personal jll packages.

JuLIP is demanding Dierckx v0.4, though it’s not obvious why because the older versions that depended on it never set a compatbility bound for it. The few versions of ASE do require JuLIP v[0.6.0, inf), but it’s not made apparent where the upper 0.8.2 bound is coming from. The log doesn’t often explain its work because of how deep dependency conflicts can go, especially when you start involve the dozens of other packages in your environment, and project files don’t often reflect the stricter compatibility bounds implied by its own dependencies.

Here it suggests BinaryProvider is demanding Dierckx v0.5, which strictly conflicts with the earlier demand. Again, it’s not apparent why because BinaryProvider never depended on Dierckx (it was the other way around for Dierckx v0.4). The implication is v0.4’s BinaryProvider bounds conflict with something else’s.

I’d definitely try nsajko’s suggestion to add ASE to a new environment first and see what other packages of interest you can get away with adding. Unfortunately dependency resolution is complicated enough to effectively be a black box to us, and it’s generally only feasible for package versions that existed at around the same time. Adding inactive or archived packages to an environment otherwise 5+ years in the future is a dice roll. You may even have to downgrade Julia itself; ASE doesn’t restrict minor versions of Julia v1, but its dependencies might.

7

I tried to install ASE in a clean environment and it failed:

 [3f19e933] + p7zip_jll v17.4.0+2
        Info Packages marked with ⌃ and ⌅ have new versions available. Those with ⌃ may be upgradable, but those with ⌅ are restricted by compatibility constraints from upgrading. To see why use `status --outdated -m`
    Building Dierckx → `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/956bfe5c4f9b794545f6527424fc0294cc5decbe/build.log`
    Building ASE ────→ `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/6ec49ba1888d4748bca4472ff8f1ea424db6777f/build.log`
ERROR: Error building `ASE`: 
pip 24.0 from /usr/lib/python3/dist-packages/pip (python 3.12)
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.
    
    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.
    
    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.
    
    See /usr/share/doc/python3.12/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
ERROR: LoadError: failed process: Process(`/usr/bin/python3 -m pip install --upgrade --user ase`, ProcessExited(1)) [1]

Stacktrace:
 [1] pipeline_error
   @ ./process.jl:565 [inlined]
 [2] run(::Cmd; wait::Bool)
   @ Base ./process.jl:480
 [3] run
   @ ./process.jl:477 [inlined]
 [4] pip(pkgname::String)
   @ Main ~/.julia/packages/ASE/GfCjR/deps/build.jl:22
 [5] top-level scope
   @ ~/.julia/packages/ASE/GfCjR/deps/build.jl:35
 [6] include(fname::String)
   @ Base.MainInclude ./client.jl:494
 [7] top-level scope
   @ none:5
in expression starting at /home/ufechner/.julia/packages/ASE/GfCjR/deps/build.jl:28

caused by: PyError (PyImport_ImportModule

The Python package ase could not be imported by pyimport. Usually this means
that you did not install ase in the Python version being used by PyCall.

PyCall is currently configured to use the Python version at:

/usr/bin/python3

and you should use whatever mechanism you usually use (apt-get, pip, conda,
etcetera) to install the Python package containing the ase module.

One alternative is to re-configure PyCall to use a different Python
version on your system: set ENV["PYTHON"] to the path/name of the python
executable you want to use, run Pkg.build("PyCall"), and re-launch Julia.

Another alternative is to configure PyCall to use a Julia-specific Python
distribution via the Conda.jl package (which installs a private Anaconda
Python distribution), which has the advantage that packages can be installed
and kept up-to-date via Julia.  As explained in the PyCall documentation,
set ENV["PYTHON"]="", run Pkg.build("PyCall"), and re-launch Julia. Then,
To install the ase module, you can use `pyimport_conda("ase", PKG)`,
where PKG is the Anaconda package that contains the module ase,
or alternatively you can use the Conda package directly (via
`using Conda` followed by `Conda.add` etcetera).

) <class 'ModuleNotFoundError'>
ModuleNotFoundError("No module named 'ase'")

Stacktrace:
 [1] pyimport(name::String)
   @ PyCall ~/.julia/packages/PyCall/1gn3u/src/PyCall.jl:558
 [2] top-level scope
   @ ~/.julia/packages/ASE/GfCjR/deps/build.jl:30
 [3] include(fname::String)
   @ Base.MainInclude ./client.jl:494
 [4] top-level scope
   @ none:5
Installing Dependencies of `ASE.jl`: `ase` and `matscipy`
`ase` was not found, trying to install via pip. If this fails,
please file an issue and try to install it manually, following
the instructions at `https://wiki.fysik.dtu.dk/ase/install.html`

(tmp) pkg>

This is on Linux.

It depends on some Python libraries that cannot be installed the same way as in the past.

Suggestion:

  1. try to use Julia 1.10. BinaryProvider is no longer supported with Julia 1.11
  2. try to install the required Python dependencies first

Or just don’t use this package. I would say, installing it is too difficult for a less experienced person. This can happen with unmaintained Julia packages, in particular if they depend on code written in other languages.

8

That’s indeed the case. See [BinaryProvider] Make it not installable on Julia v1.11+ by giordano · Pull Request #114503 · JuliaRegistries/General · GitHub.

1 Like
9

That explains the julia compatibility line to me then, the project file in the archived repo doesn’t restrict Julia v1 and I wasn’t aware the registry can separately do so (and I’m generally ignorant of how registries work). I guess effectively de-registering a package for newer Julia versions makes more sense than just patching a stricter upper bound in the package because the latter wouldn’t (?) stop Pkg from downgrading the package to a version with the previous upper bound. That makes me wonder though, what’s the proper way of introducing stricter upper bounds to a package that wouldn’t be evaded by downgrades?

1 Like
10

When Pkg resolves dependencies it needs to find out how involved packages depend on each other and what their compatibility constraints are. One possible way to do that is to download each package and read the Project.toml files. This isn’t exactly a snappy procedure and might require downloading packages/versions that eventually turn out not to be among the resolved dependencies. The Pkg designers didn’t consider this to be a satisfactory solution (to put it mildly) and instead decided to collect the information needed for resolving dependencies in registries. As a consequence it is the registry information that is the ground truth for Pkg.

Naturally the registry information is initialized from the information in Project.toml but it can be changed. A drawback of doing that is that the registry information diverges from the corresponding Project.toml, which can cause confusion when investigating dependency problems. An advantage is that incorrect compatibility constraints can be fixed retroactively. Specifically the linked PR upper bounded the Julia compatibility for every registered version of BinaryProvider.

2 Likes