Install own fork of package instead of "official" version

Tooling Package Management
1

I have a fork of a package. That package is a dependency of many other packages, some of which I use heavily. How can I install my fork so that the dependent packages use my fork instead of the “official” dependency? is it just as simple as remove the “official” pkg and install my fork instead?

2

If you’re developing your fork, I would ] dev Pkg. Then it’ll use your local version.
Otherwise, you could ] add path_(optionally_URL)_to_your_fork.

4 Likes
3

That’s what I was thinking, first ]rm the official package, then ]add my fork on GitHub. Not at home at the moment, so can’t test it. I’m afraid it may produce some conflict.

4

why?

5

(untested)

I believe if you keep the original uuid/pkg name, then the other packages of your local installation don’t care if your git remote is the original package address or your fork one…

Of course, if you are then developing your fork further and adding versions, then you may have problems…

6

Why not ]dev? This is exactly what that is for.

2 Likes
7

Probably a good idea is to add your fork to a specific environment, activated by, for example,

] activate "MyFork"

] dev MyFork # or add your fork

Then you can use your fork without creating conflicts with the installation in the main or other environments.

1 Like
8

To “use” a package different from its official version, but not to develop it, one can also use add SomePackage.

9

]dev is the right answer if you’re just doing this for yourself on your own machine, but I think it won’t be reproducible (that is, one won’t be able to use the Manifest to instantiate it), right?

10

I don’t know, but I’m only doing it for myself before a new release of the package with the fixed gets released. There is already a PR for that.

1 Like
11

In that case, ] dev souds like the right call (or ] add ThePackage#fork-name). Just remember to do ] free ThePackage once the PR is merged and tagged.

12

I still do not anderstand.

pkg> activate "MyFork"

Is "MyFork" just a arbitrary label?
And what about

pkg> dev PackageName

After I have cloned the package “PackageName” the code is cloned as described here.
No I wonder how can I link this to the official repository.
The package I would like to work on and maybe create a Merge Request is hosted
on the platform github.
What would be the next step to file a MR?

13

The environment is a suggestion to not mix the use of your own fork of the package with the official version of the package in all other uses of it you may do in other contexts.

Suppose you forked the package, you then can:

  1. Create a new environment. This is done simply by creating a directory, starting Julia and doing
import Pkg; Pkg.activate(".")

That will activate an environment with the same name of the directory.

  1. Add your for:
import Pkg; Pkg.add(url="https://github.com/user/MyFork.jl")

This will create the Project.toml and Manifest.toml that contain the information about the packages used in that environment.

That won’t intefere with the use of the “oficial” version of the package in other contexts, meaning, in environments different from that one.

Afterwards, just start julia again in the same directory and use ] activate . to activate the environment where you are working with that version of the package.

If you are developing the for of the package, instead of Pkg.add(...) use Pkg.develop(...))

1 Like
14

Thank you for your fast reply!

Is it mandatory to be sure that the current directory:

pwd()

is identical with the root directory of the repository-clone?
Is is also possible to use an explicit path instead, e.g.:

import Pkg; Pkg.activate(raw"C:\data\git_repos\extern\EquivalentCircuits.jl")
15

These are two different things. If what you want is “simply” develop your fork of the package, yes, just activate the project of that package (which is what you do there). You can also do that by going to the directory and starting julia with julia --project. This is the standard way to develop a package. (If you are using VSCode, developing that directory does all that).

Another thing (which is, apparently, the original question of this thread), is how to use that fork, not necessarily to develop it. In this case, you can add the fork, as I mentioned, to any other environment.

The environment and the versions of the packages are not associated, necessarily. You can dev a package in any environment. Only it is common to develop a package in the environment of the package itself, though that is not mandatory, and particularly common if one is developing two packages at the same time.

16

Sorry I have to admit, I am still lost.
Is the following correct:
1.) fork a repository
2.) clone the repository on a local machine
3.) activate the local root directory of the package via activate
Here I struggle already.
Is is mandatory to go there via cd()
and then specify as location "."
or is it appropriate to specify the full directory name, e.g.:

import Pkg; Pkg.activate(raw"C:\data\git_repos\extern\EquivalentCircuits.jl")

5.) change the content of the fork in the remote repository
6.) pull the fork from the remote repository
7.) next …
Is this already all I need to do to use the new pulled fork?
Do I need to use a Pkg command to enable the use of the new content
of the pulled fork?
E.g. is a restart mandatory?

17

The problem is that you are mixing three things: the activation of the environment, the use, and the development of the local fork.

  1. The activation of an environment is important so that your changes to this local fork of your package do not affect other uses of the package in other instances of Julia. For instance, let us say you are developing something in Plots, you wouldn’t want that a perhaps broken local fork of Plots does not let you use Plots in other scripts. Thus you want to isolate the fork in a an environment. It can be any new environment. For instance, you can start all this by doing:
import Pkg; Pkg.activate("MyNewEnv")

and this will create a directory MyNewEnv to contain the files of that new environment.

  1. If you are developing that package, it is frequently convenient and practical to just use the environment that is already defined by the package you are developing. Then you activate the directory of the package, as you propose (or by cd’ing to it, or by loading in VSCode).

  2. To develop the package, use:

import Pkg; Pkg.develop(raw"c:\data...\MyPackage") # not sure if you need that raw
using Revise
using MyPackage

By using Revise before the package, the changes to the functions of the package will be automatically tracked, and you can modify the code and rerun the functions to test them. VSCode sort of does all that automatically for you.

  1. To just use the package in the local folder, use import Pkg; Pkg.add("c:\....\MyPackage"); using MyPackage. Preferably in a specific environment, again not to mix your local version of the package with the “official” version that might be in some other script.
2 Likes
18

Thanks that clarifies. :slight_smile:

First I decide in which environment I would like to work. This can be done in at least three
alternative ways:

  • VScode: Open new window and use the command open folder
    (such a root directory of an Julia-Pkg-Environment includes a file Project.toml)

  • Inside Comand Line Interface (CLI): move to the environment root dir via command
    cd and give the command import Pkg; Pkg.activate(".")

  • Explicit Pkg.command with the name of the environment, if no argument is given,
    the native Julia version specific environment will be taken: import Pkg; Pkg.activate()
    or import Pkg; Pkg.activate("MyEnvironmentName")

If I introduce a new environment I need to install inside the current environment the
packages that I need inside this particular environment.
With the command import Pkg; Pkg.status() I can see which packages are installed
inside the chosen / current environment.

After some trial, I prefere to seperate the folder of the package I am working on and
the host folder of a specific Julia-Pkg-Environment.
Default location of the environments can be printed by using:

import Pkg; Pkg.envdir()

If I create a new Julia-Pkg-Environment via:

Pkg.activate("MyDevEnv") # no directory path is specified

This new environment does not include installed packages, that needs to be done
by means of Pkg.add("PackageName").
In Julia version v1.6.7 the corresponding file: Project.toml & Manifest.toml will be created in a subfolder of

joinpath(Pkg.envdir(), "vX.Y") # "vX.Y" might be: "v1.6"

On MS-windows in Julia v1.8.3 the default environment folder is located in the personal profile folder / home-directory.
As soon as a package is added to this new environment, e.g. by:

import Pkg; Pkg.add("Revise")

In Julia v1.6.7 this folder will be populated with the two environment definition / configuration files Project.toml & Manifest.toml.
In Julia v1.8.3 however the environment will be set-up in the current folder,
which can be displayed via pwd()

If I would like to switch back to the original environment of the current Julia-Version
I can use the command activate() without argument:

Pkg.activate()
1 Like
19

Regarding the activation of user defined environments see also: julia-environments-list

20

I am still struggling.
I have used the parameter url of command Pkg.add() to be sure that I add my own fork to the new userdefined environment MyDefEnv as follows:

Pkg.add(url=raw"C:\folder\to\my\local\fork\EquivalentCircuits.jl")

And I can see that this development package / this fork is attached to the environment:

(@MyDevEnv) pkg> st
      Status `C:\Users\stefanpofahl\.julia\environments\v1.6\MyDevEnv\Project.toml`
  [da5bd070] EquivalentCircuits v0.2.1 `C:\folder\to\my\local\fork\EquivalentCircuits.jl#master`
  [5789e2e9] FileIO v1.16.0
[...]

But unfortunatly, it is still the standard package (not my fork of the package) that is used.
If I use in addition the command Pkg.develop(path=) the following error-message is thrown:

Pkg.develop(path=raw"C:\folder\to\my\local\fork\EquivalentCircuits.jl")

The error message is:

ERROR: expected a `name` entry in project file at `C:\folder\to\my\local\fork\EquivalentCircuits.jl\Project.toml`

What do I miss?