Can't activate base with conda 4.5.4

[dsentinel]

Updating to conda 4.5.4 broke xonsh for me. After some fiddling everything seems to work but the following

$ conda activate

CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
If your shell is Bash or a Bourne variant, enable conda for the current user with

    $ echo ". /Users/lloyd/anaconda3/etc/profile.d/conda.sh" >> ~/.bash_profile

or, for all users, enable conda with

    $ sudo ln -s /Users/lloyd/anaconda3/etc/profile.d/conda.sh /etc/profile.d/conda.sh

The options above will permanently enable the 'conda' command, but they do NOT
put conda's base (root) environment on PATH.  To do so, run

    $ conda activate

in your terminal, or to put the base environment on PATH permanently, run

    $ echo "conda activate" >> ~/.bash_profile

Previous to conda 4.4, the recommended way to activate conda was to modify PATH in
your ~/.bash_profile file.  You should manually remove the line that looks like

    export PATH="/Users/lloyd/anaconda3/bin:$PATH"

^^^ The above line should NO LONGER be in your ~/.bash_profile file! ^^^

$ conda activate base
No environment 'base' found

If I start xonsh in bash with the base env active everything seems ok, until I activate another env and need to get back to base.

[CJ-Wright]

Would there be any interest in having a CI build which uses https://anaconda.org/conda-canary? That channel publishes cutting edge conda, so we could potentially see/fix breakage before it makes it into production (if this is a case where the conda API moved).

[dsentinel]

Would there be any interest in having a CI build which uses https://anaconda.org/conda-canary? That channel publishes cutting edge conda, so we could potentially see/fix breakage before it makes it into production

That's sounds like a great idea. 

(if this is a case where the conda API moved).

I think this is the case.For the issue above. I think adujsuting the xonda alias to match the conda new beahvior could fix it, but I think there's more. Conda also now nests activated envs. 

[gforsyth]

@dsentinel -- have you upgraded xonda, too? It's working fine for me on 4.5.4

[gforsyth]

Also, make sure that you have loaded xonda using xontrib load xonda

[dsentinel]

have you upgraded xonda, too?

# Name                    Version                   Build  Channel
xonda                     0.2.5                      py_0    conda-forge

Also, make sure that you have loaded xonda using xontrib load xonda

I am. It's in my . xonshrc

$xontrib list
...
xonda               installed      loaded
...

It's working fine for me on 4.5.4

conda activate with no args works for you? I doesn't seem like it's handled: https://github.com/gforsyth/xonda/blob/f9fedaafcaa7571670e6ca684e994547fb21d0d0/xontrib/xonda.xsh#L125-L137

[gforsyth]

Ooooh. Ok, gotcha. Thanks for the clarification.

Right now, xonda does not follow the model that conda just introduced. The base anaconda bin directory should always be on your PATH. However, xonda doesn't do the thing that conda (used to) do and just prepend the environment to the front of the PATH and subject you to cross-loading nightmares.

So for now, just use conda in the "old" way and everything should still work.

[dsentinel]

I can live without conda activate, but I need conda activate base How would I do this the old way?

$ conda activate base
No environment 'base' found

xonda can't find the base env

[CJ-Wright]

Would source activate base work?

[gforsyth]

The "old" way is that base is not an environment, it's a default install. So for me, on my $PATH is ~/miniconda3/bin and I just use that. If you want to activate an environment, you do conda activate envname (which also has tab completion for your environments). To return to base, just conda deactivate

[gforsyth]

And to clarify a possible point of confusion here, I added conda activate functionality to xonda before it existed upstream, mostly because source activate is problematic in xonsh since activate isn't xsh-compatible.

[dsentinel]

No,

$ source activate base
xonsh: To log full traceback to a file set: $XONSH_TRACEBACK_LOGFILE = <filename>
Traceback (most recent call last):
  File "/Users/lloyd/anaconda3/lib/python3.6/site-packages/xonsh/__amalgam__.py", line 11982, in run
    r = self.f(self.args, sp_stdin, sp_stdout, sp_stderr, spec)
  File "/Users/lloyd/anaconda3/lib/python3.6/site-packages/xonsh/__amalgam__.py", line 11803, in proxy_two
    return f(args, stdin)
  File "/Users/lloyd/anaconda3/lib/python3.6/site-packages/xonsh/__amalgam__.py", line 18321, in source_alias
    'does not exist.')
RuntimeError: must source at least one file, activatedoes not exist.

[dsentinel]

Ahhh, this makes good sense. As a new user I expected conda in xonsh to behave the same as in other shells. I'll give it a go, now knowing what to expect. Time permitting, I may start a pr to have xonda mirror conda. I'm thinking that translating condas new alias shouldn't take much.

Thanks guys for the time and responses. I really want to fall in love with xonsh, but a shell is so fundamental hangups quickly have me jump ship.

[dsentinel]

I'm going to close this issue. Thanks again for the help.

Is there any interest / plans to have xonda behaviour match that of conda? I realize it's a bit tricky, and possibly more complicated / time consuming than worth the effort.

[gforsyth]

There are efforts to have a xonsh-compatible activate in conda. If it's built in to conda, so much the better. My main reasons for writing this in the first place were to fix environment activation in xonsh and also to prevent the cross-wiring of PATH that can happen by prepending directories to PATH.

[scopatz]

@gforsyth - I agree with you. This stuff should make it into conda itself.

[scopatz]

I made an attempt at that in the past. I think it was merged, but it currently fails to activate.