~cloud-images/cloud-images/+git/wagon:0.9

Last commit made on 2020-04-28
Get this branch:
git clone -b 0.9 https://git.launchpad.net/~cloud-images/cloud-images/+git/wagon

Branch merges

Branch information

Recent commits

667a541... by asdf <email address hidden>

update setup.py's author & email to cloudify

575680a... by =?utf-8?q?=C5=81ukasz_Maksymczuk?= <email address hidden>

release 0.9

d59ea11... by asdf <email address hidden>

tests: a more specific utility for running wagon

13a17cc... by =?utf-8?q?=C5=81ukasz_Maksymczuk?= <email address hidden>

mark py2.6 as supported

it's not tested in CI, but yeah, it works. Maybe we'll test it in CI.
Anyway, I want to be able to install it.

8d12e5c... by =?utf-8?q?=C5=81ukasz_Maksymczuk?= <email address hidden>

drop/rewrite several tests

see github comments, which explain why every test was dropped

3cc7f86... by =?utf-8?q?=C5=81ukasz_Maksymczuk?= <email address hidden>

drop unicode_literals

it's somewhat a bad idea to use unicode_literals; we thought it was
a good idea back then, but now both the python docs, and the community
(eg. click) suggest not using it.
Also the cloudify py3 porting procedure recommends against it

0f8ad0f... by =?utf-8?q?=C5=81ukasz_Maksymczuk?= <email address hidden>

rewrite platform/distro utils

the distro try/except importerror might be just this. Both distro's
and platform's `linux_distribution` have the same signature anyway.

Also, use distutils instead of the wheel.pep425tags call. This makes
us not necessarily depend on wheel itself (although actually doing
anything will still need wheel, of course. But wheel, similar to pip
and venv, doesn't consider its submodules public api, so this might
well change).
PEP 425 itself defines the platform as just that distutils call,
with those replaces.

For now, keep the distro requirement in setup.py as it was before.
In the future, maybe we should make it a hard requirement on py3.7+

8db2336... by =?utf-8?q?=C5=81ukasz_Maksymczuk?= <email address hidden>

rewrite subprocess calls

pip is used often, so let's make a utility to get its path. This
is just a bit nicer.
Also, add a hack to support 2.6. Small price to pay.

56430f6... by asdf <email address hidden>

replace `pip.exe` calls with `python -m pip` calls

`python -m pip` is also supported, for both pip and virtualenv,
as per the documentation; it's preferred here because it then requires
us to only find the path to the python executable and not worry
about the other ones

additionally, it might happen that pip/venv are installed in a way
that doesn't install the executable itself, but `python -m` always works

a7dc359... by asdf <email address hidden>

_run: drop shell=true