I have a few questions regarding the use of Pkg. I know there are some other threads with similar titles but I could not really find a clear answer to my questions.
It’s also hard to make a MWE, since my questions are more about good practices than really coding.
Here it goes:
Lets say I have my non registered package A that depends on my non registered package B.
I have a few options:
a) I can decide not to add B to the environment of A. I can do everything I want if I work purely on my local machine.
b) I want to have packages A and B on github (or gitlab) to share them with my colleagues. To avoid warnings I add github/omerchiers/B.jl to the enivronment of A.
Here comes my first problem. If I just add B to A, then the version of B will be fixed. That’s fine for my colleagues, but I want to continue developping B normally. I could dev B, but I don’t want that for my colleagues. Which choice should I make? I guess I misunderstand something from the hole process.
It seems to be recommended (juliacon2019 presentation by Kristoffer Carlsson on Pkg) to systematically dev your local packages under development. Is dev a purely local command? Or is it somehow also reflected in project.toml that appears on Github?
c) I usually keep my own packages in a well defined place, not .julia/dev. If I do dev B, how can I avoid it to be copied to .julia/dev?
It seems that Project.toml should always be committed in the repo. Is this also true for Manifest.toml?
I give version tags to my commits. project.toml doesn’t seem to take this into. How can I put a version tag in Project.toml? By hand editing? Or is there a command for that?
That’s about it for now.
Thanks in advance,
Olivier
For unregistered packages, I would suggest creating a registry and your colleagues only need to add that registry. And you can find many other discussions here and on Registrator.jl
Yes, only local. Unless you commit and push your changes to github…
Then consider making a temp dir and activate that environment. Then it will not affect .jlia/dev. By the way, I remember that dev B will not copy B into .julia/dev. Correct me if I’m wrong.
No. But for projects (instead of packages), the Manifest.toml file do help to reproducibility.
The tag info will appear in Manifest.toml but not Project.toml.
If A is an “application”, you can just commit the manifest and instantiate. If it is a package, then your best current option is registering it, or running a private registry.
For unregistered packages, I would suggest creating a registry and your colleagues only need to add that registry . And you can find many other discussions here and on Registrator.jl
I never looked into registries. I will see how hard that is.
Yes, only local. Unless you commit and push your changes to github…
I’m sorry, I’m not sure if I fully understand. Can you give some more details?
The tag info will appear in Manifest.toml but not Project.toml.
Yes indeed. I just saw that. But the tags in Manifest.toml seems to be stuck on 0.1.0.
Somehow for my unregistered package I cannot do https://github/omerchiers/MyPackage.jl@v0.2
I have to put the commit SHA1 even though I pushed my tags to github.
Here I mean that, by ] dev X, you can modify everything about that package on your local computer. But nothing will be updated to your remote github automatically. Unless you manually cd /path/to/X && git add . && git commit -m "notes" && git push
Yes, that’s true. I remember that there used to be a discussion about it but I can’t find it right now. (One argument is that the tag on github can be changed to point to a different commit, which hurts the reproducibility)
Yes, that’s true. I remember that there used to be a discussion about it but I can’t find it right now. (One argument is that the tag on github can be changed to point to a different commit, which hurts the reproducibility)
yeah sorry, I should have gotten that