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.
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.
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?
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
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).
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.