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.
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 activateSatPrecip, using dnt2str will work.
As the error message in your screenshot suggests, you need to Pkg.add or Pkg.developdnt2str 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?
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.
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.
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 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.
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.
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.
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
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 MyPackagein 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.