Usage with different python versions
naphta opened this issue · 3 comments
I've only skimmed the repository so forgive me if the answer is already buried somewhere but what's the recommendation for using this with multiple python versions? For example using pipenv you can specify the python version used to install the requirements, could you do such a thing as that with this?
I ask because in my team at least we actively use 2.7, 3.4 and 3.7 and it'd be good for it to know which version to be using at any given point.
pickley
currently defaults to system python, but can install/package with any python.
Which python to use can be specified via command line: pickley --python 3.6 install ...
(or -P
for short). Value for --python
can be:
- full path to a python installation, like for example
/usr/bin/python
- command name like
python2.7
orpython3
- short form like
py3.6
of3.6
or even just36
- you can also be more specific like
3.7.3
A config file can also be provided in <base>/.pickley/config.json
(example if you dropped pickley in ~/.local/bin: ~/.local/bin/.pickley/config.json
).
Example config:
{
"python_installs": "~/.local/pyenv/versions",
"python": {
"3.7": "awscli"
},
}
The above example would tell pickley to look at ~/.local/pyenv/versions
for python installations (in addition to what you already have on $PATH
).
Then default to 3.7 for awscli
(if no --python
specified).
I plan to provide better support for this:
- respect module's
python_requires
(if there's any), don't default to system python for everything - document how python versions are found :)
- see what's the best way out there people are getting their "clean python" installations, and see if it could be made to work with as little configuration as possible :)
Few examples (without config):
pickley -P3.7 install tox
pickley -P `which python3` install tox
pickley -P ~/.local/pyenv/versions/3.7.3 install tox
@zsimic Great answer thank you.
In that example configuration above for pointing the default installation to pyenv would that be a good idea for doing by default? Just do a quick check for pyenv if it's installed; if so default to it?
If that is a simple enough thing to do I don't mind opening up a feature branch / pull request to add that feature.
Yes, that would make sense to do I think, as pyenv is pretty popular.
Didn't do it yet as I tried to keep it simple and reach 100% test coverage first.
Next things I plan to do are (in this order):
- fix edge case around dashes vs underscores in package names (currently broken: you can't install
foo-bar
, have to manually state it asfoo_bar
...) - provide an
upgrade
command (accepting 0 or more args) - write a good documentation
- respect
python_requires
if package specifies one (so not to have to configure anymore) - fancier python search (so stuff like auto-detect pyenv)
Contributions absolutely welcome! :)