How to further develop my package branch

I am working on a branch of the package DataStructures.jl. Until now I have been using git in a rather ad-hoc and tedious manner to get my commits posted to github. I would prefer to use a proper Julia package dev method. However, I don’t know the correct command to get started. Below is what I tried, which gave me an error message. If I used add instead of develop as suggested by the error message, then will the package be stuck in the state in which it was downloaded? Please feel free to give me a verbose answer since I haven’t grasped the differences between Pkg.add and Pkg.develop nor how they interact with git.

julia> Pkg.develop(PackageSpec(name="DataStructures", url="https://github.com/StephenVavasis/DataStructures.jl", rev="sortedcontainerupdates"))
ERROR: rev argument not supported by `develop`; consider using `add` instead
Stacktrace:
 [1] pkgerror(msg::String)
   @ Pkg.Types C:\Users\vavasis\AppData\Local\Programs\Julia-1.7.1\share\julia\stdlib\v1.7\Pkg\src\Types.jl:68
 [2] develop(ctx::Pkg.Types.Context, pkgs::Vector{Pkg.Types.PackageSpec}; shared::Bool, preserve::Pkg.Types.PreserveLevel, platform::Base.BinaryPlatforms.Platform, kwargs::Base.Pairs{Symbol, Base.TTY, Tuple{Symbol}, NamedTuple{(:io,), Tuple{Base.TTY}}})
   @ Pkg.API C:\Users\vavasis\AppData\Local\Programs\Julia-1.7.1\share\julia\stdlib\v1.7\Pkg\src\API.jl:189
 [3] develop(pkgs::Vector{Pkg.Types.PackageSpec}; io::Base.TTY, kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ Pkg.API C:\Users\vavasis\AppData\Local\Programs\Julia-1.7.1\share\julia\stdlib\v1.7\Pkg\src\API.jl:149
 [4] develop(pkgs::Vector{Pkg.Types.PackageSpec})
   @ Pkg.API C:\Users\vavasis\AppData\Local\Programs\Julia-1.7.1\share\julia\stdlib\v1.7\Pkg\src\API.jl:144
 [5] #develop#14
   @ C:\Users\vavasis\AppData\Local\Programs\Julia-1.7.1\share\julia\stdlib\v1.7\Pkg\src\API.jl:141 [inlined]
 [6] develop(pkg::Pkg.Types.PackageSpec)
   @ Pkg.API C:\Users\vavasis\AppData\Local\Programs\Julia-1.7.1\share\julia\stdlib\v1.7\Pkg\src\API.jl:141
 [7] top-level scope
   @ REPL[10]:1

If you use develop then you either track a local repository or clone a remote one and then track the local clone. From then on you decide what branch you’re checking out, so I assume that’s why the rev keyword doesn’t exist for develop. It would change anywaywith every commit you’re making on your branch.

Thanks for getting back to me so quickly! However, I don’t understand your answer. What does “track the local clone” mean? When you say “It could change anyway with every commit”, what could change? And is that good or bad?

Here is what I want to do: get a copy of the current version of the code from my github repository (the branch called sortedcontainerupdates of DataStructures.jl), save it in my local file system (ideally, not in ~/.julia, which is not automatically backed up, but in ~/OneDrive, which is backed up), edit it over the course of a week or two, make commits (?is that necessary?), test it with Pkg.test() as I revise it, re-run Documenter as necessary, and eventually use git push to send the revised code back to my repository on github.

You run git clone url_of_repo local_path and then you have the repository on your computer. You can check out any branch that you want with git checkout branch. Then run ] dev local_path in an environment of your choice. The repository is now installed in that environment, “tracked” means that when you make changes to the code and restart Julia, this changed code will be loaded. (Can be done with Revise.jl in a running session as well). Packages that are “added” on the other hand are meant to be immutable. When you are satisfied with your changes you can commit and push them.

2 Likes

Thanks very much, that worked! One last question: What workflow is associated with specifying a remote URL in the ] dev command?

How to contribute to existing package might help?

The repo will be cloned to .julia/dev by default, that folder can be changed too. But you can also do ] dev --local URL and then the repo will be cloned into ./dev relative to whatever your working directory is