search

ionelmc / cookiecutter-pylibrary

Enhanced cookiecutter template for Python libraries.
BSD 2-Clause "Simplified" License
1.25k stars 206 forks source link

Python versions controls #4

Closed pydanny closed 1 year ago

pydanny commented 10 years ago

First off, this is INCREDIBLE!

Okay, gushing aside, what would be really nice is the ability to specify which versions of Python you want bootstrap.py to manage. I know I can hand-craft that in the configuration, but I always forget to do that.

Again, this is amazing. Wow.

ionelmc commented 10 years ago

Hey, thanks.

Can you elaborate a bit about what python versions? There's a list of them in setup.cfg (https://github.com/ionelmc/cookiecutter-pylibrary/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/setup.cfg#L56). You mean something like a configuration file in a well known location (like ~/.pylibrary.rc) for the python versions?

ionelmc commented 9 years ago

@pydanny Any response here?

nealmcb commented 4 years ago

I'm not sure what bootstrap.py is supposed to do in the first place. It could use a docstring. So my attempt at a clarification may be off-base. But this seems related.

I'm running into tox errors like:

ERROR:  py35: InterpreterNotFound: python3.5

I think it would help to at least indicate in the pylibrary documentation how to specify the set of Python versions for tox to test against. I guess that is mostly by changing envlist in tox.ini, and presumably also removing unneeded entries in basepython = ....

But since the set of versions changes with different libraries, prompting the user for such a list would be another more approach that wouldn't require manual adjustment later.

nealmcb commented 4 years ago

Note also that besides tox.ini, changes are needed in .travis.yml and setup.py. So if not using the same versions, important to change the options before running, or ask for them during the run.

dHannasch commented 4 years ago

Changing envlist in tox.ini should be the only thing you need to do. (Of course, you can then remove unneeded entries if you want to declutter.)

bootstrap.py will take the envlist in your tox.ini and rewrite your .travis.yml to use the same versions. You bring up something interesting --- it sounds like you don't want to run the same Python versions on Travis as when running tox locally? You definitely don't want anything to do with bootstrap.py in that case, but can you elaborate on when you would want to do that? (That's relevant to an interest of mine --- graceful handling of the case when the test runner does not have all the Python versions mentioned. https://github.com/ionelmc/cookiecutter-pylibrary/pull/173 This came up on Travis since for a while Travis did not have Python 3.8, and obviously that'll happen again for a while the next time a new Python version comes out. As a side effect, it would mean no one would ever get ERROR: py35: InterpreterNotFound: python3.5 locally either...tox would just go with whatever Python happened to be available.)

Unfortunately cookiecutter does not seem to support specifying multisets very gracefully.

ionelmc commented 4 years ago

Perhaps what is really needed here is just a 'python_versions' field in cookiecutter.json so you can select only the python versions you need.

dHannasch commented 4 years ago

I wonder if it might make sense to specify Python versions in an environment variable on the test runner, defaulting to running everything in the envlist. (Of course, the envlist itself could be edited if some Python versions will definitely not be relevant to the project, and could be controlled by python_versions in cookiecutter.json, though we still run into the problem of selecting a multiset in cookiecutter.) That way different runners could run different Python versions. Unfortunately it might not be possible to use an environment variable to select Python versions in .travis.yml. https://stackoverflow.com/questions/33735992/travis-ci-using-repository-environment-variables-in-travis-yml

nealmcb commented 4 years ago

Thanks, folks. I like the idea of adding a 'python_versions field in cookiecutter.json.

Testing and documenting options for running local tests with a different set of environments would also be nice, but isn't the thing I was feeling an itch for.

ionelmc commented 1 year ago

Closing this cause it's too old and from what I've learnt from getting my projects through multiple python versions this is pointless. Having an option that specifies the list of python versions won't save you much pain - you'll always fight against various deprecation and feature removal in python, CI providers, tool providers and god know what. It's hopeless anyway, and a feature like this would only make unnecessary work for me. This template should just provide the "currently maintained pythons" as a fixed, non-changeable set.