Skip to content

CLN: Fixes to conda environment names #23851

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
datapythonista opened this issue Nov 22, 2018 · 8 comments · Fixed by #23866
Closed

CLN: Fixes to conda environment names #23851

datapythonista opened this issue Nov 22, 2018 · 8 comments · Fixed by #23866
Labels
CI Continuous Integration Clean Dependencies Required and optional dependencies good first issue
Milestone

Comments

@datapythonista
Copy link
Member

We have some inconsistency regarding the names of the conda environment. At the moment, all environments for the CI are named pandas, and the environment created locally following the set up instructions (and using environment.yml) is named pandas-dev.

Then, inside several scripts (e.g. ci/code_checks.sh) we do a source activate pandas. Which means that the script works well in CI jobs, but it fails locally unless we also have a pandas environment locally.

Another thing is that in the CI config we use a CONDA_ENV environment variable, and we ignore the conda environment names in the yaml files.

What I would do is:

  • Use pandas-dev as the environment name in all our conda yaml files
  • Create the environments with the environment name in the used yaml file (do not override with -n $CONDA_ENV as we do now)
  • Do not use source activate inside the scripts (use it in the steps in the CI config files when needed). This way when running scripts locally, the current environment will be used

@jreback @TomAugspurger @jorisvandenbossche any objection?

@datapythonista datapythonista added CI Continuous Integration Clean Needs Discussion Requires discussion from core team before further action Dependencies Required and optional dependencies labels Nov 22, 2018
@jreback
Copy link
Contributor

jreback commented Nov 22, 2018

this is ok

@datapythonista datapythonista added Effort Low good first issue and removed Needs Discussion Requires discussion from core team before further action labels Nov 22, 2018
@charlesdong1991
Copy link
Member

i will take a look!

@datapythonista
Copy link
Member Author

Thanks @charlesdong1991, let me know if you need clarifications or help.

@charlesdong1991
Copy link
Member

Hi, @datapythonista , sorry, i think i do need your help, following your explanation above, i did a small modification to change pandas to pandas-dev, not sure if it's the right place to do... and appreciate a lot if you could give more clarifications

@datapythonista
Copy link
Member Author

The main changes required are:

  • In ci/deps/*.yaml change the name of the environments from pandas to pandas-dev
  • Do a grep for CONDA_ENV, and remove the -n $CONDA_ENV in the conda env install calls. And remove the definitions of it, as it won't be used anymore.
  • Do a grep for source activate and move the activations inside the scripts (mainly in ci/) to the CI configuration files, in the place before those scripts are called

For example, in ci/incremental/build.sh there is a source activate $CONDA_ENV. This should be removed from there, so if we call the script in our machines the active environment is used. And for the CI to work, a source activate pandas-dev should be placed in .travis.yml before the call to build.sh, so the environment is active when that is called.

@h-vetinari
Copy link
Contributor

I'd like to add one more location to this: doc/source/style.ipynb
For compiling the docs, I always have to change the name of the kernel in there, to make ipython use the right one:

  "metadata": {
   "kernelspec": {
    "display_name": "Python 3",
    "language": "python",
+   "name": "pandas-dev"
-   "name": "python3"
  },

@TomAugspurger
Copy link
Contributor

TomAugspurger commented Nov 22, 2018 via email

@h-vetinari
Copy link
Contributor

@TomAugspurger Yes, of course, but I don't want my python3 kernel spec to point to the dev environment. If we're already talking environment names (and the default from environment.yml), I think this is a reasonable adaptation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Continuous Integration Clean Dependencies Required and optional dependencies good first issue
Projects
None yet
5 participants