Dependency on an un-registered fork

General Usage
1

Hello,

(short) I’m contributing to a package (say B) that depends upon a unregistered patched fork (fork/A) of a registered package (A). I’d like to make sure that if a user uses B, it uses fork/A and not A if by any chance they already have A on their system. This seems to require that they add fork/A explicitly which seems odd?

(long) this is if the short paragraph above doesn’t make sense

  • A is a registered and reasonably mature package with a (currently) slow development schedule
  • B is a package I’m contributing to that has using A in it
  • A has a bug which causes B to not work properly
  • fixing the bug well is not trivial though a simple hack is possible and works fine but is unlikely to be merged in A, this simple fix is applied in my fork of A: fork/A

I’ve added fork/A to B using the usual package approach (activate . and add url/fork/A) and it shows up in the Manifest.toml as it should. If a user adds B on a system that doesn’t already have A somewhere, it works fine and uses fork/A.
However, on a system where A is already present, if I just do add url/B it uses A and not fork/A even though it is fork/A that is mentioned in the manifest (why?)

I can bypass this problem by requiring users to add the patched fork explicitly doing

pkg> add url/fork/A
pkg> add url/B

that works fine but is not ideal because it forces the user to go from A to fork/A on their system (in this case it changes nothing for them but they may still not want to do it e.g. if they’re using an older version of A for another project of theirs)

So I guess my questions are:

  1. why does it use A instead of fork/A if A exists on the system even though the manifest specifies fork/A
  2. is there any better alternative than the double add above or requiring users to activate an environment every time they want to use the package?

thanks!

2

An enviroment’s Manifest.toml is only used if an enviroment is activated.
Only the Project.toml is used if a project is depended upon.

If you can’t get you patch merged upstream,
then you could perhaps monkey patch your dependency from within your pacakge.
via overloading its methods with your patched ones.

3

Makes sense, thanks!

I did consider monkey patching too but there’s a lot of nested dependencies so I was hoping for an alternative. It might just be the better option though, cheers!

4

I have perhaps been overly depending on ‘Base.delete’ and monkey patching.

Somewhere between Julia 1.0 and 1.2, new warnings against the practice seems to have been added:

** incremental compilation may be fatally broken for this module **
WARNING: method deletion during Module precompile may lead 
to undefined behavior

This may motivate many hardly necessary forks, which is quite bad for the development of the ecosystem. Is there a workaround?