Modifying and testing a registered package in a directory outside of .julia

package
git

#1

I am in the process of editing a file in a standard package (SpecialFunctions). For better or worse, I’ve already done my work using the standard git procedure, but outside the .julia directory structure. I can’t find any advice on how to test my updated branch of the package. I would appreciate help as I’ve already created havoc with some kludgy guesses.

To elaborate, I have cloned https://github.com/JuliaMath/SpecialFunctions.jl/ , started a new branch on my local machine ~/Julia/Testing, and pushed this to https://github.com/matthew-wingate/SpecialFunctions.jl/ . In my julia session, I’d like to use my new branch rather than the registered master branch.

Is there a way to toggle between versions of packages, in the way a python user would call import mytestdir/special vs import scipy.special? I have a feeling the solution lies in Pkg.init(), but there isn’t enough documentation there for me to follow. Also it seems I’d have to keep pushing changes to my git-hub repo; it would be more convenient to test before making commits, I’d think.

I’ve found https://docs.julialang.org/en/release-0.6/manual/packages rather late in the day. From this I gather that I should be doing my work all within julia, although as a git tyro, this feels even more likely to lead to workflow problems.

Thanks in advance for any help.


#2

I did a workflow video here:

Notice that Julia packages are just Github repos. So you can Pkg.checkout("MyPackage") and now you’re on master, do your stuff, push to your remote, Pkg.test("MyPackage"), and then Pkg.free("MyPackage") to go back to the release version. That’s why I think it’s easiest to just work from .julia/v0.x/MyPackage.


#3

Or symlink it there.


#4

I tried that, but git was unhappy, complaining about a detached HEAD. I’ll try more carefully. Thanks.


#5

I made an issue related to this on Juleps a few months ago:

https://github.com/JuliaLang/Juleps/issues/31


#6

Really? I was under the impression, that Julia packages are git repos and github is just the default sharing platform.


#7

I don’t know if this may be too dirty, but since you have a copy of your repository in Github, you might change your local copy of METADATA inside ~/.julia, so that your link to the “SpecialFunctions” package points to your fork of the package, instead of the original one.

You may find the file with the target url in ~.julia/v0.X/METADATA/SpecialFunctions/url (with “X” equal to the version of Julia you are using - 0.6 if you are working with the latest released version).

Then, if I’m not wrong, Pkg.update() should update that package to your fork. I have not tested that myself, so I’m not really sure if this works or it would break…


#8

Yes, that is correct. I wrote that down incorrectly.


#9

Thanks for the suggestion, but is this syntax depricated? I find

MethodError: no method matching add(::String, ::String)
Closest candidates are:
add(::AbstractString, ::VersionNumber…) at pkg/pkg.jl:117

Stacktrace:
[1] include_string(::String, ::String) at ./loading.jl:515


#11

Thanks, that was very helpful! GitKraken was a sanity-saver!