Management of Packages in Julia

Hi All,

I’m using PkgTemplates to create new custom Pkgs for my own use, and as per PkgTemplate defaults, they save to the .julia/dev/ directory.

I was able to call my first package, SatPrecip, with “using SatPrecip”. However, the second package I create, dnt2str, cannot be found at all even though they are found in the same .julia/dev/ directory. Might anyone know what the issue is?

The screenshot of my projects and codes in the Juno IDE are found below.

Best
Nat!

52%20(2)

You can add or dev your package to your registry.

] dev path/to/your/package

Alternatively for doing development, you can use this simple code that pushes the path of your current package to the registry temporarily .
Set developing to true. For real usage, you need to add your package to your registry and set the developing to false.

Thanks!

I didn’t need to do this for the first project I created though, so that’s what got me wondering.

I would not change the LOAD_PATH and use Pkg instead to keep track of dependencies. That’s the whole point of having packages, after all.

So the question is what SatPrecip's Project.toml looks like. It should have dnt2str as a dependency. If so, once you activate SatPrecip, using dnt2str will work.

As the error message in your screenshot suggests, you need to Pkg.add or Pkg.develop dnt2str while in SatPrecip's environment.

Instead of writing out all the details, it would probably be easier to read Notes on the Julia language (see section on packages).

Mmmm actually I wanted SatPrecip and dnt2str as separate projects and packages, not dnt2str as part of SatPrecip. Is there a way to have both available in the .julia/dev/ folder (because they are still very new projects) without one being a dependency on another?

I misunderstood.

Then you could just cd to the directory that would want to work on (e.g. .julia/dev/SatPrecip and issue >pkg activate . followed by using SatPrecip.

But I have a feeling you want to do something else / more?

The general point is: for using X to work you either need to activate X’s directory (.julia/dev/X) or you need to add X as a dependency to the environment that you are working in.

You could also add .julia/dev/X to the LOAD_PATH but this really defeats the point of having packages.

2 Likes

Adding to the previous answer:
If the goal is to use/develop both SatPrecip and dnt2str together, but not have them be dependencies of one another, then a new environment can be activated and those two packages can be dev'd in.

This can be done by making/navigating to a new folder and then

]activate .
]dev SatPrecip
]dev dnt2str

Hopefully the packages get identified since they are in the .julia/dev/ folder.
Then it should be possible to use/develop both packages at the same time.
When opening a new Julia session in the same folder, the ]activate . line will need to be repeated.
(Or skip the activating part and just dev the packages to make them available everywhere, but I’m not a fan of that)

Though I’m not sure why using SatPrecip worked out of the box.

I … am not sure either, likely I did something that isn’t quite right either HAHAHA.

But thanks so much! I will try the dev option.

Update: The ]dev option works and I’m using it now.

Another question, I keep getting this error during my first time using SatPrecip and ClimateTools (another personal package) when I restart julia:

┌ Warning: Package ClimateTools does not have Dates in its dependencies:
│ - If you have ClimateTools checked out for development and have
│ added Dates as a dependency but haven’t updated your primary
│ environment’s manifest file, try Pkg.resolve().
│ - Otherwise you may need to report an issue with ClimateTools
└ Loading Dates into ClimateTools from project dependency, future warnings for ClimateTools are suppressed.

I have tried using Pkg.resolve() but this doesn’t solve the issue. In the Manifest.toml file I can see that Dates is added as a dependency in the main environment (which is what I am developing my packages in).

I think the package itself may need to be activated before resolving, e.g.

]activate path/to/ClimateTools
]resolve # or, ]add MissingDependency

I do suggest that you adjust your workflow to work with rather than against the package manager.

If you develop all packages while the Main Julia environment is active, you are mixing together the dependencies for all the packages that you are working on.

What you want is for each package to be a stand-alone, self-contained code base. All dependencies should be defined in its Project.toml.

My suggestion is to keep the Main environment minimal. Just Pkg.add development tools (Revise, OhMyREPL, etc).

When you want to work on package A, it’s best to activate its environment, and explicitly add or dev dependencies there.

As for the ClimateTools package, it sounds like you need to >pkg add Dates in its environment.

2 Likes

It’s a bit … complicated per se. I’m still very used to a MATLAB-kind of workflow where if I needed to I could just point the program to look at a certain directory that stores relevant codes.

So, for example in this case, ClimateTools and SatPrecip are different packages. But in the end, I still would want SatPrecip to be able to use some functions from the ClimateTools package, because ClimateTools is a general set of personal-developed functions that can be used for a variety of purposes while SatPrecip is meant for the download and plotting of specific datasets. But I am developing ClimateTools at the same time while I am developing SatPrecip.

In this case, what sort of workflow should I use?

You are describing a very common workflow:

pkg> activate /path/to/SatPrecip
pkg> develop /path/to/ClimateTools

This will allow you to import ClimateTools from within SatPrecip. In general, before you work on any project, you first have to Pkg.activate() it.

I agree with the advice given by @hendri54: people should rarely modify LOAD_PATH.

2 Likes

Advantage of my code which uses LOAD_Path is that the code runs wherever it is on the drive.
You don’t need to add or dev anything. You just cd to the directory and run the code (very similar to Matlab)!

For real usage or distributing, it makes sense to add the package permanently.

What if I was working on another package (e.g. ERApkg), while at the same time developing ClimateTools?

Is it possible to have ClimateTools be developed on two different activated environments/packages or whatever the term is?

Apologies, very new to Julia, but would like to learn about using Julia most efficiently in its native format.

Sure, pkg> develop /some/path just tells Pkg to directly use whatever package happens to be at /some/path. You can think of it as the simplest(least structured) way to add a dependency to the active environment. Multiple packages can depend on the same package, this is not an issue.

Please ask more questions if this is still confusing :slightly_smiling_face:

1 Like

It would probably be a good idea to read the Pkg.jl docs.

Think of Pkg.develop as editing the Project.toml for the currently active environment (and only for that environment). develop adds a line to that environment that points to (by default) julia/dev/MyPackage. That’s all that happens.

Then, when you issue using MyPackage in this environment, Julia looks up where to find MyPackage in the environment’s Project.toml. Any changes you make to the code in julia/dev/MyPackage gets “tracked.”

Pkg.add edits Project.toml adding a line that points to https://github.com/user/MyPackage.git with one fixed sha (commit) code. That’s the version of the code that will be used in that environment.

So you can develop MyPackage in one environment and add MyPackage in another. No Problem.

1 Like