Allow option to setup my own environment with environment.yml

[UnHumbleBen]

Is your feature request related to a problem? Please describe.
It is not clear how to activate my own requirement
Describe the solution you'd like
I have a environment.yml file in my repository. I would like to run these commands

conda env create -f environment.yml
source ~/anaconda3/etc/profile.d/conda.sh
conda activate my_env

Currently, the second command does not work because it is not the correct path to conda.sh. I would like documentation for where the conda.sh file is located.

Describe alternatives you've considered
I have not found an alternative

[basic-ph]

I got stuck on the same issue during the Christmas holiday and during an email conversation with @s-weigand he suggested to me the use of source activate my_env.
Here's my Github action YAML file as an example:

name: CI
on: push

jobs:
  test:
    name: Pytest Testing
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Conda setup
        uses: s-weigand/setup-conda@v1
        with:
          update-conda: true
          python-version: 3.7
      # env activation as suggested by @s-weigand
      - name: Conda environment creation	
        run: |
          conda env create -f environment.yml	
          source activate feat	
          pip install -e .
      # env activation as it should be
      # - name: Conda environment creation	
      #   run: |
      #     conda env create -f environment.yml	
      #     conda activate feat	
      #     pip install -e .
      - name: Testing with pytest
        run: |
          source activate feat
          pytest

Let us know if it works also for you.

PS: I think Sebastian is planning to add two more options to deal with this type of situations:

• the choice of which shell initialize for conda usage (see here),
• the setting to indicate a conda environment YAML file.

[s-weigand]

Sorry for the late reply and thx @basic-ph for helping @UnHumbleBen in the mean time.

Concerning the conda activate <env> usage:

As @basic-ph already said, at the momemnt the way to go is, calling source activate <env> (glad it worked), which this action also does internally when activating the base env on a posix system.

setup-conda/src/conda_actions.ts

Lines 62 to 67 in 66ced16

	// write temp shell script to activate conda
	temp.track()
	const stream = temp.createWriteStream({ suffix: '.sh' })
	stream.write('source activate base')
	stream.end()
	await exec.exec('bash', [stream.path as string])

One problem I see with conda activate <env> is the initialization (conda init <sheel name>), which is for it to work, since it might require to restart the shell.

IMPORTANT: You may need to close and restart your shell after running 'conda init'

This is especially problematic due to the fact how shell commands are internally.

Future plans:
When I got a bit more time I want to deprecate the use of s-weigand/setup-conda@master, which tells users to use major versions instead, since the other changes I want to implement are breaking changes.

New options:

• activate-env (Default: ''): Name of the env to be activated, if 'deactivate' deactivates current environment.
• env-file (Default: ''): Path to a environment.yml file, relative to the project root, which should be used to create a conda environment.
• requirement-file (Default: ''): Path to requirements.txt file, relative to the project root, which should be installed by pip in the current environment.

Deprecated option:

• activate-conda: Since this functionality will be replaced by activate-env

Possible solution for the conda activate <env> problem:
I could add an option only-activate-env (Default: false), which skips the whole setup part and just activates the env provided by activate-env. This would make changing between environments during a workflow platform independent.

If you have any thoughts about this, I'm always happy to get feedback.

PS.:
@basic-ph I think that calling source activate feat a second time, before the tests isn't needed.
At least in my tests, after activating the base env once, it stayed activated the whole session.
Could you please confirm this? 😃

[basic-ph]

@basic-ph I think that calling source activate feat a second time, before the tests isn't needed.
At least in my tests, after activating the base env once, it stayed activated the whole session.
Could you please confirm this?

sorry for the very late reply...
with this workflow file:
https://github.com/basic-ph/feat/blob/dev/.github/workflows/continuous_testing.yaml
the test is failing as you can see here:
https://github.com/basic-ph/feat/runs/689905699?check_suite_focus=true

maybe I'm messing around with something...

[s-weigand]

Hmmm I get a 404 error, is it a private repo?

[basic-ph]

Yes, I'm sry...completely forget.
this is the actual yaml file:

name: CI
on: push

jobs:
  test:
    name: Pytest Testing
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Conda setup
        uses: s-weigand/[email protected]
        with:
          update-conda: true
          python-version: 3.7
      # env activation as suggested by @s-weigand
      - name: Conda environment creation
        run: |
          conda env create -f environment.yml
          source activate feat
          pip install -e .
      - name: Testing with pytest
        run: |
          pytest```

[s-weigand]

@basic-ph Also maybe open a separate issue 😉
You can post the workflow and the error code there.
Adding the language of a code block, also helps a lot 😄