Depend on a specific commit?

General Usage
1

I’m almost dead certain I have seen this asked before, but I just can’t find it.

Assume I have a package A which needs a later version of a package B than what is released.

The problem with just adding a version which works it is that I want other projects to be able to depend on A. Maybe I did this the wrong way, but it seems like checking in a manifest from A does not prevent an old version of B to be loaded as the manifest plays no role in this case.

I know that the “right way” is to push for a release, but this has been tried with B already and there seem to be some good motivations to not release it which does not directly have to do with the functional status of the package. I’m always happy to add a pair of hands to solve some problem, but I can’t provide the needed resources unfortunately.

Fwiw, I put the following at the top of the main module file and while it is not pretty it seems to get the job done:

    # Can't depend on specific commits AFAIK, this is a hacky-wacky workaround until the people at ClusterManagers do a new release
if Pkg.API.dependencies()[Base.UUID("34f1f09b-3a8b-5176-ab39-66d58a4d544e")].version < v"0.4"
    @info "Too old version of ClusterManagers detected! Adding updated version"
    Pkg.add(url="https://github.com/JuliaParallel/ClusterManagers.jl"; rev="dde400e953cd8cf631802866e164697019805a92")
end
2

Yes, it is. You can’t specify [compat] bounds on commits — Julia’s package architecture explicitly relies on SemVer.

In the specific case you link, the underlying reason happens to be that the package is unmaintained. To quote from that discussion,

People relying on software that might not work is worse than them being aware of that it might not work…

You can either take up maintenance, or fork the package under a different name, potentially making a release in a private registry. See

2 Likes
3

Thanks Tamas,

A is basically a subset of B which is being tested (by A) and where A does reside in a private registry. As such, there exist a commit of B for which A is fully functional. I thought this was a less clumsy solution than forking the entire B and putting it in a private registry together with A.

I can live with the hack above for now but I was thinking there is somewhere in the package resolving mechism where it is smoother to hook in. I fully respect if the people who would know how to do this don’t want to condone this type of actions though :slight_smile:

Just to make it clear again: I would gladly help in maintaing B (ClusterManagers), but I don’t own the resources needed to test it. I’ll chime in the issue just to get clarifiction that resources (compute clusters) is what is needed to maintain it.

1 Like