Pkg.test about pkg.jl HOT 9 CLOSED

I think the first step is just to duplicate existing Pkg.test as a pkg> test command. Behavior: by default (no arguments) test all packages in the current manifest; if names are given test those packages and their dependencies; maybe a --deps=[no|yes] option to control whether or not to test dependencies or not. Does that seems like a sane interface? Want to work on it?

from pkg.jl.

Why would you want to test the dependencies of your package? Presumably you are working under the assumption that those are working correctly?

from pkg.jl.

To see if everything is working. How would you expect it to work?

from pkg.jl.

Same as Pkg.test("Package") works except it is spelled pkg> test Package

from pkg.jl.

Ok, fair enough. In that case there should be a [-r|--recursive] option that tests all recursive dependencies of the listed packages as well. What would pkg> test by itself do? Maybe pkg> test can test the current project? Then pkg> test -r would be a natural way to test everything.

We probably also want to think a bit about syntax for filtering tests, but maybe that can wait for another day. pkg> test --filter=... comes to mind, applying to all the following package names.

from pkg.jl.

Recursive dependency testing is a good idea.

Getting to feature parity with Pkg2 (being able to just test one package) seems like a good starting point.

from pkg.jl.

Implemented the basic stuff in #33, what is lacking to get up to Pkg2.test is to resolve the dependencies and test only dependencies and for that we need to determine how a package should store that information.

from pkg.jl.

Will one be able to use this framework for "local" packages? Currently I am using a hack for this, and I was hoping this would be obsoleted by Pkg3; or lacking that, some hook would be available to maintain this functionality.

from pkg.jl.

Yes, this will work with local packages. There is no difference really. Test-dependencies are now supported.

from pkg.jl.