Feature request: dev time dependencies

[oxinabox]

Similar to #727

This idea has been thrown around a few times on Discourse and Slack.
So I thought I would write it up, or at least start to

Consider the case where your active enviroment is a project you have ] deved.
This is kinda as I understand it an intended way to do package development.
It lets you do ] test to test the project and ]add adds deps to the project.

This means you do not have your normal enviroment.
So the idea of a dev time dependency is a set of packages that are installed when you run dev.

There exist packages you want to be using as a developer.
With Revise.jl now being the most common way to interactive editting,
one really wants it at dev time.

Below is a list of packages that exist to be used at Dev time.
I break them into two categories.
user-dev: for packages that the use of depends on the preference of the developer.
I.e. you can develop the package without them, and different developers may want to use them or not.
project-dev: for packages that you actually can't develop the project without,
because they do some part that is required for the dev process, like generating code.
(You can develop parts of the project with out them, but there are some parts that you really shouldn't touch).

user-dev packages:

• Revise.jl
• Rebugger.jl
• OhMyREPL.jl
• OhMyLog.jl

project-dev packages

• Documentor.jl
• Literate.jl
• ReferenceTests.jl *
• DataDepsGenerators.jl

Further to this list, just about any package can be a project-dev package, if you have some development scripting that needs it, like JSON.jl perhaps.

• ReferenceTests.jl is perhaps an odd one, it is a Dev time and Test time dep, because you need it to edit/author your test files; and of course the check them.
  But it might be, that it is best if all test time dependencies were installed at dev time,
  since that makes it easier to mess around with the tests manually/interactively.

[KristofferC]

You can still load packages in a lower environment in LOAD_PATH in the REPL. So if you install Revise.jl in the v1.0 environment, activate a dev environment, you can still do `using Revise´ in the REPL (or a script).

[oxinabox]

That does mostly solve it, for user-dev packages,
I think leaving this open because deploying project-dev packages to new contributors is still a problem.

[KristofferC]

I think leaving this open because deploying project-dev packages to new contributors is still a problem.

I would have thought that would just be

git clone .../MyProject.jl.git
julia --project=MyProject

[StefanKarpinski]

I think having a way to ask target environments in general would be useful. Then you could imagine having this:

[extras]
TestPkgA = "<uuid>"
TestPkgB = "<uuid>"
DevToolA = "<uuid>"
DevToolB = "<uuid>"

[targets]
dev = ["DevToolA", "DevToolB"]
test = ["TestPkgA", "TestPkgB", "DevToolA"]

In the manifest, one would have

[[DevToolA]]
targets = ["dev", "test"]

Which would let the system know that the package should only be loadable in the dev and test target environments.

In the mean time, you can just have a git repo called DevTools.jl that has a project and manifest with dev tools in it.

[ExpandingMan]

Note that this has suddenly become a lot more significant now that Debugger has a release. You can always just go ahead and use Revise or OhMyREPL all by themselves in whatever environment and you won't even get any warnings. Debugger, however, requires a using Debugger in the package itself in order to set breakpoints. The current behavior is that you get a single warning for doing this. It's not a big deal, since it's only one warning when the package loads, but it would be nice to have a way around it.

[oxinabox]

I do not think my original idea is good anymore,
becuase if anything we want to be pushing away from [extras] and [targets] (including test),
and moving more towards having seperate Project.tomls,
like is done for Documenter.
but perhaps there is scope for [targets] to reference secondary Project.toml,
this I think might require more thought.
Which someone other than me might have done.

[ExpandingMan]

The simplest solution I think of would be to simply have a [dev] or [optional] section which silences warnings if the package is imported and nothing else. Again, the only case which I can think of in which this would be a good idea is debuggers, but that seems like a fairly important use case.

[KristofferC]

Debugger, however, requires a using Debugger in the package itself in order to set breakpoints.

Only for in source code breakpoints and we could come up with a way to do this without having Debugger loaded in the package. It just needs to be something unique in the code that we know marks a breakpoint.

[ExpandingMan]

Only for in source code breakpoints and we could come up with a way to do this without having Debugger loaded in the package. It just needs to be something unique in the code that we know marks a breakpoint.

What do you have in mind? Adding a @bp to Base that only does anything if the debugger sees it?

[oxinabox]

Take this to another issue?