CLN: Fixes to conda environment names

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?

[h-vetinari]

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"
  },

[h-vetinari]

@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.