I think that ignoring the conda alternative in this context is a mistake, and will lead to more confusion, not less.

You can use venvs within a conda env (in fact this is my normal everyday setup on my work machine...).

Agree with @efiring here. I don't think I've used a venv since before conda was a thing & I'd be majorly frustrated/confused with making a venv in my conda env

For a conda user the disadvantage of venv is that it is yet another arcane and peripheral thing to have to learn and keep straight. What is the advantage of using one within a conda env rather than just using another conda env?

I'm not dead set against it, someone just needs to write the instructions on how to set them up and activate them. (Note that there were no instructions for either before...)

someone just needs to write the instructions on how to set them up and activate them.

Will do. May take a day or two to really test that the described setup works. You can move this forward without conda or wait. Both is fine with me.

@timhoffm I think @efiring was also tasked with adding conda, so maybe co-ordinate w/ him?

I'm tempted to merge as an improvement, and then let new changes be on top?

No comments on the PR per se (except to agree with @efiring's comment above), but I'm wondering why dev workflow items are milestoned for the already much-delayed 3.2.0? This is easily something that could be added later.

@h-vetinari mpl practice is to usually milestone against the next release & if it isn't release critical than it gets remilestoned before the release is cut.

The instructions use the python command which is not available to most Linux users by default from next year on. Replacing it with python3 wouldn't hurt.

When following the new instructions on current master, I'm getting

[...]
lib/matplotlib/docstring.py:40: in __call__
    func.__doc__ %= self.params
E   KeyError: 'scale'

when running pytest.

switching to py3 seems fine, done.
the error re: docstrings still looks like a messed up dev environment.

Is it really true, that calling python does not work anymore on linux, once Python 2 is removed? I can't believe that. On my machine python is just a link to python2. I'd assume that that link will point to python3 in the future.

This is explicitly allowed by https://www.python.org/dev/peps/pep-0394/#for-python-runtime-distributors.

Is it really true, that calling python does not work anymore on linux, once Python 2 is removed?

Well, there is the Debian policy https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-base:

The python binary package must also ensure that /usr/bin/python is provided, as a symlink to the current python2.Y executable.

Perhaps, at some point in the future, /usr/bin/python will be something other than python2, but it won't be Jan 1, 2020. Since mpl only supports Python3 from then on, we better be specific.

@anntzer in that case, please go through the whole file and replace all occurrences of python.

Once you're in the env you can use python (the env will provide that unsuffixed name for you); the suffixed name is only necessary to set up the env.

Another issue: pytest is not installed in the venv, so it will take the one from system. That's probably not what you want.

ah yes, that can be fixed with the usual dance of python -mpytest.

Nice. More: python setup.py build_ext --inplace doesn't install the dependencies, so when running pytest, you get a lot of import errors.

You're supposed to run pip install -ve . at least once, and setup.py build_ext -i only on later runs.

I didn't catch that from the new docs. Perhaps wording should be something like

[...]
C-extension source (which might happen if you change branches) you will need to run

    python -mpip install -ve .

or run `python setup.py build_ext --inplace` if you've done that at least once before.

It's in the paragraph immediately above the edit? (you may want to expand the unmodified part of the file in the diff view)

You're right, I had missed that when looking at the diff. 👍

Next: When running pytest, I'm getting lots of file-not-found errors like

E           FileNotFoundError: [Errno 2] No such file or directory: '/path/to/matplotlib/result_images/test_arrow_patches/fancyarrow_test_image-expected_svg.png'

The directory contains

fancyarrow_test_image-expected_pdf.png
fancyarrow_test_image-expected.png
fancyarrow_test_image-expected.svg
fancyarrow_test_image.pdf
fancyarrow_test_image_pdf.png
fancyarrow_test_image.png
fancyarrow_test_image.svg

Can you please provide a full log of what you did, starting from setting up a clean venv?

Can you please provide a full log of what you did, starting from setting up a clean venv?

$ ls ~/matplotlib-env/
ls: cannot access '~/matplotlib-env/': No such file or directory
$ python3 -mvenv ~/matplotlib-env/
$ source ~/matplotlib-env/bin/activate
$ python -mpip install -ve .
[...]
Successfully installed cycler-0.10.0 kiwisolver-1.1.0 matplotlib numpy-1.17.4 pillow-6.2.1 pyparsing-2.4.5 python-dateutil-2.8.1 six-1.13.0
Cleaning up...
Removed build tracker '/tmp/pip-req-tracker-aczpokn_'
$ pip install pytest
[...]
Successfully installed attrs-19.3.0 importlib-metadata-1.3.0 more-itertools-8.0.2 packaging-19.2 pluggy-0.13.1 py-1.8.0 pytest-5.3.2 wcwidth-0.1.7 zipp-0.6.0
$ python -mpytest --maxfail=1
[...]
E           FileNotFoundError: [Errno 2] No such file or directory: '/path/to/source/result_images/test_arrow_patches/fancyarrow_test_image-expected_svg.png'

Strange, can't repro locally.

What's matplotlib.__version__? I assume this is a clean fresh clone? Do you have inkscape installed? What's the traceback on the FileNotFoundError (pytest --full-trace may help)?

What's matplotlib.version?

$ python -c "import matplotlib; print(matplotlib.__version__)"
3.1.1.post2790+gce7115d3d

I assume this is a clean fresh clone?
Indeed.

Do you have inkscape installed?

$ inkscape --version
Inkscape 1.0beta1 (fe3e306978, 2019-09-17)

The weird thing is that the directory contains all kinds of files,

fancyarrow_test_image-expected_pdf.png
fancyarrow_test_image-expected.png
fancyarrow_test_image-expected.svg
fancyarrow_test_image.pdf
fancyarrow_test_image_pdf.png
fancyarrow_test_image.png
fancyarrow_test_image.svg

but not fancyarrow_test_image-expected_svg.png. It appears some renaming issue.

Well, the issue seems unrelated to this PR and I don't want to delay it. Filed and issue report at #15999.

Ah yes, I think inkscape 1.0 changed their command line interface and we'll probably need to fix some stuff on mpl's side to support that, can you downgrade to inkscape<1.0 for now?

Okay, I downgraded and got the test to pass now (after #16002). LGTM.

Even without conda, this is an improvement. Conda-based configuration can follow in a separate PR.

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v3.2.x
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 a070ad53324c5a8478db85f4fa0e980eeb3d2ece

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #15961: Be more opinionated for setting up a dev env.'

4. Push to a named branch :

git push YOURFORK v3.2.x:auto-backport-of-pr-15961-on-v3.2.x

5. Create a PR against branch v3.2.x, I would have named this PR:

"Backport PR #15961 on branch v3.2.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.

Backport would need at least also #15476 and #15569. Maybe more.

Giving up on backporting, because the local freetype change #15476 won‘t be in 3.2.