Usage with different python versions

[naphta]

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.

[zsimic]

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 or python3
• short form like py3.6 of 3.6 or even just 36
• 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

[naphta]

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

[zsimic]

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 as foo_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! :)