Make it simpler to contribute to packages (Pkg 3)

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


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

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.

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?

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

@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 ``
  Updating git-repo ``
┌ 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