allow activate take context&pkgspec

[Roger-luo]

I find this would solve my own use case related to #38 that creates a shared environment from a path with a little bit more code creating the PackageSpec and Context but I believe these two API in Pkg is quite stable. I'm not sure what is the proper way of doing this PR, but I only need 1.7+ support

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 81.60%. Comparing base (787fdb4) to head (341704b). Report is 14 commits behind head on release-1.7.

Additional details and impacted files

@@               Coverage Diff               @@
##           release-1.7      #39      +/-   ##
===============================================
+ Coverage        81.17%   81.60%   +0.43%     
===============================================
  Files                3        3              
  Lines               85       87       +2     
===============================================
+ Hits                69       71       +2     
  Misses              16       16              

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[Roger-luo]

bump @oxinabox any chance to review this?

[oxinabox]

I do not understand this solution. I don't think it is great extending our public API with methods that take 2 things from the private API. But i don't understand this code, or how it is used

[Roger-luo]

I do not understand this solution.

so one can create a Context and PackageSpec to specify a location of the project test environment to activate

I don't think it is great extending our public API with methods that take 2 things from the private API.

What would be the proper solution tho? should we change the convention of activate to activate(path)?

[oxinabox]

What would be the proper solution tho? should we change the convention of activate to activate(path)?

We could introduce a thing that checks if the path exists, if so activate it, else use the module name. Or visa-versa.

Or we could introduce a new activate_path.

I don't actually know how the current activate(::AbstractString) works or what exactly it does. I always use TestEnv.activate()