I am still curious to know how to simply add a path to where julia’s Pkg
is looking for packages - like PkgTemplates
does.
This was be the most simple for me.
It’s just dev
ing them like you did, see here.
My guess is that the package was dev
-ed on your local machine, but add
ed on the other machine. The difference here is that an added package points to a specific commit, but a dev-ed package looks at every change in the source files and re-compiles the package even without them being committed. Perhaps you had not committed your changes after adding foo
? In this case adding the package will not get you foo
but dev
ing it will. Perhaps dev
is what you want anyway.
Thanks a lot for the explanation!
I realize this is an old thread but the answer seems not quite satisfactory.
I don’t think you can do this with the REPL form of the package manager launched with ]
You can do it easily with the Pkg set of functions as here:
using Pkg
Pkg.add(path="/Users/<hiding my name>/Dropbox/Covid Modeling/Covid-ILM")
The only additional complication as variously discussed above is that the directory must contain a git repository for the code of the package: you’ll have a hidden directory named .git within the path. And all of the code files will have been added.
And your package at the specific path meets the minimal requirements for being a package: that is there must be a valid Project.toml
file there. It need not be as complicated as all of the overly elaborate and confusing (almost to the point of being misleading) documentation describes[1]. Look at one of your installed packages and see its Project.toml file. Make a copy and chop away and change it to include the minimum needed. Of course, this file must be tracked in git.
[1] I say this only because the documentation for Pkg and creating packages serves several needs. In particular, it provides direction on how to develop and maintain registered packages–essential documentation, but somewhat makes the tasks of using packages that you’ve written yourself seem more complicated than it is. I think I’ll write the absolute minimal guide to writing your own packages that you never intend to add to Julia’s public registry for packages. I do not mean to say that there is anything wrong with the way Pkg works. It was brilliant and flexible to bootstrap on github (or really any git server for privately shared packages) and many problems suffered by some other languages have been avoided. Hats off–it’s only that comprehensive documentation can make a simpler use case seem harder than it actually is.
Thanks a lot for the explanation!
I had another issue regarding this. I am running this package on two machines, and the home folder is different on these machines.
To solve this I used develop ~/myfolder/MyPackage
.
You are adding the package to two different instances of Julia. You can use the appropriate path on each machine.
- Lewis
Thanks! But the code is shared on both machines. That is why I want things to be compatible.
It looks like the module is actually called pendulum
? Is that the reason?
no. I am sorry for the confusion: at the moment there is no problem. using ~
to indicate the home folder works great.
Once you’ve used the package manager to install the package on each machine, your code will invoke that package as ‘using mypkg’. Your code will be the same regardless of which machine it runs on. The name space for installed packages doesn’t refer to the file system.
Am I missing something about what you need? If so, Let’s look at that.
- Lewis
No, you’re right.
But since I am dev
-ing this package, I need to add a path, namely
] dev ~/src/MyPackage
This means that as long as in both machines that package is located at ~/src/MyPackage
everything will work properly.
(The issue was that beforehand I was not sure that ~
would work as indicating the home folder, but now I see that it works).
Fair enough.
I test the work I am doing on my similar local package using Jupyterlab. So, I include the statements
# Run this when actively modifying the code in the package
**using** Pkg
Pkg**.****develop**(path**=**"/Users/<myname>/Dropbox/Covid Modeling/Covid-ILM")
in a cell in the notebook where I run simple tests. You are correct that I could use ~ to replace the first 2 steps of the above path. I am not clear on how long the “develop” status stays “open”.
Then, I edit away in VS Code.
You could open the REPL, declare you are deving the package before you start a coding session.
I was actually wrong here!
When I dev
using ~
, it puts in the path to the home folder in a hard-coded way in the Project.toml
file. This is not what I want since I am using two machines with two different home folder paths.
I am now trying out adding a relative path. I hope that works well.
I prefer ]dev
over ]add
because you don’t have to reinstall the pkg everytime you make change