Make it simpler to contribute to packages (Pkg 3)

General Usage
1

I stumbled over the following situation:

  1. I develop an app – so I’m in the app’s folder/environment (I used pkg> init to set it up; wondering if I should use pkg> generate since the documentation does not say… but it seems that pkg> generate should be used for developing a new package, not for developing an app)
  2. I add a package and then do using ThePackage
  3. the package has a dependency, ThePackageDep, which throws warnings / errors

Now say you want to fix these.

You can’t do pkg> dev ThePackageDep in the app’s env – you actually have to do pkg> dev ThePackage in the app’s environment. Then you have to go into ThePackage and there do pkg> dev ThePackageDep. I can imagine that it can be even more interesting if the problem is in a dependency of a dependency.

Also, for warnings, you can’t really tell where it’s coming from. Because there’s no call stack, so you don’t know whose dependency is throwing the warnings.

So maybe:
a. we can have something like
pkg> dev ThePackage > ThePackageDep which would do a nested dev
b. add a stack trace to warnings too

3 Likes
2

Hm, there should be no need to dev ThePackage. It should be enough to just do dev ThePackageDep and then using ThePackage should use the potentially modified ThePackageDep

3

Thanks - I’m pretty sure I tried that, but ThePackage kept using the non-dev dependency. However, let me try it again. I’ll follow up.

4

Also, as a personal curiosity. I thought that each package / app has its own env if it has a Project.toml file – so they manage their own versions of dependencies.

Thus, doing pkg> dev ThePackageDep in the app, shouldn’t switch just the app’s version of the dependency to the dev one? While leaving all the other apps and packages still using the original/published one?

Or doing dev on a package, makes all the existing packages use the dev version on the local Julia instance?

5

Only the “active project” (the one that shows when you do pkg> st) decides what dependencies are loaded (by looking in the Manifest.toml of the active project. The manifest for other projects/packages/apps is not used.

1 Like
6

@kristoffer.carlsson Yes, that works correctly. Sorry, false alarm. I’m not sure why I saw the warnings referencing the non-dev package. Must’ve messed up something - redone from scratch and worked fine…

julia> using SearchLight
WARNING: Base.STDOUT is deprecated, use stdout instead.
  likely near /Users/adrian/.julia/dev/SearchLight/src/Logger.jl:6
in #LumberMill#12 at /Users/adrian/.julia/packages/Lumberjack/xug2/src/lumbermill.jl

(v0.7) pkg> develop Lumberjack
   Cloning git-repo `https://github.com/WestleyArgentum/Lumberjack.jl.git`
  Updating git-repo `https://github.com/WestleyArgentum/Lumberjack.jl.git`
┌ Warning: packages will need to have a [Julia]Project.toml file in the future
└ @ Pkg.Types Types.jl:578
 Resolving package versions...
  Updating `~/.julia/environments/v0.7/Project.toml`
  [ff7a09a4] + Lumberjack v2.1.1+ [`~/.julia/dev/Lumberjack`]
  Updating `~/.julia/environments/v0.7/Manifest.toml`
  [ff7a09a4] ↑ Lumberjack v2.1.1 ⇒ v2.1.1+ [`~/.julia/dev/Lumberjack`]

julia> using SearchLight
WARNING: importing deprecated binding Base.STDOUT into Lumberjack.
WARNING: Base.STDOUT is deprecated, use stdout instead.
  likely near /Users/adrian/.julia/dev/SearchLight/src/Logger.jl:6
in #LumberMill#12 at /Users/adrian/.julia/dev/Lumberjack/src/lumbermill.jl