activate in the wrong current working directory

[PatrickHaecker]

I regularly waste a bit of time because when I want to activate an environment, I need to give the path. As the absolute path is often long, I need to provide the relative one which means I need to check which is the current working directory. This is not a show-stopper, but a flow-stopper :-).

Sometimes, I manage to get it wrong and therefore activate a non-existing directory, happily add a package to the environment and spend the next minutes with debugging errors which do not fit my mental model.

Can't we just check all packages which are already added or developed when only a package name without any path information is provided for activate and activate that existing environment even if it is not in the current working directory?

I think this is probably what we want in more than 99% of the cases. In the remaining cases where you already have a package Package and want to create a new environment in the current directory with the same name, you could still activate ./Package in the package REPL.

[PatrickHaecker]

This would mirror the $PATH behavior in most operating systems (. not in the $PATH) on the shell, so should feel familiar to most users:

• If you want to start a process, just enter the binary and $PATH is being searched for it.
• When you really want to start something in the current directory, you use an explicit path like ./julia.