On 29Jul2020 11:20, Chris Green <c...@isbd.net> wrote:
>The existing code simply lives in ~/bin with a couple of modules in
>~/bin/pymods (which directory is in my PYTHONPATH).
>
>I use mercurial for configuration management of the code, directly in
>the ~/bin directory. This works fine for the sort of minor bug fixing
>and updates that I do most of the time, I'm the only user so changing
>the 'live' code isn't a major issue and I can always drop back to the
>last working version using mercurial.
Step 1 is to copy this sideways: keep the existing setup, but do the dev
in a separate directory. The Mykefile in my personal dev directory has a
"_home" target which installed the current state of play into my home
directory.
Once you have that, it is easy to make more clones to pursue things
separately.
>So, finally to the question, does anyone else have this command line
>based sort of approach and, if so, what do they do to provide a
>'development version' of a program in parallel with a working version?
To that last part, I have a personal script "env-dev" (aliased as just
"dev"), here:
https://hg.sr.ht/~cameron-simpson/css/browse/bin/env-dev?rev=tip
Feel free to copy it.
Its purpose is to run the code from the current directory by prefixing
various path environment variables, etc. Additionally it sources the
file ".env.sh" in the current directory or ancestor for customisation
beyond what it does automatically. It also utilises the venv if present.
So to run the test code I go:
$ dev the-programme ...
and it uses the scripts and modules in my development directory.
>I guess virtualenv (Python 2) and venv (Python 3) address this problem
>but they do feel rather more complex than I actually need and I'm not
>very clear how you move code from the virtual environment to 'live'.
The nice thing about a virtualenv is that you can run specific Python
versions with specific modules installed. It is easy to keep a few
around.
You utilise the virtualenv by invoking via the "python" executable
within the virtualenv. That hooks up the virtualenv for the run. (Ignore
"activate", it is a confusing source of pain IMO.)
Moving to "production" is just a matter of maintaining a production
virtualenv, using the python and modules you see fit for production.
For example, I keep a virtualenv in the "venv" subdirectory of the
development tree. I keep a personal, "production", virtualenv in
~/var/venv/3, and ~/var/venv/3/bin is towards the front of my $PATH.
Typically you keep a "requirements.txt" file in your dev tree which
specifies the modules you want. The filename is just a convention. The
to update production you'd just go:
~/var/venv/3/bin/pip install -U -r requirements.txt
where "~/var/venv/3/bin/pip" is _my_ production venv - adjust for your
own, and "requirements.txt" is the reference file you want to use.
>There's also the issue that I'm moving code from Python 2 to Python 3
>so which virtual environment should I use?
Make one of each - that way it is easy to run your tests against either
or both at once. So maybe (in your dev tree) make a "venv2" with a
Python 2 virtualenv and a "venv3" with a Python 3 one, then you can run
python out of each as required.
Also, keep a make target to build the virtualenvs. Here's mine, which
just does one based on "python3".
dev = env-dev -d $. -x
base_python = python3
venv_dir = $./venv
venv_requirements = $./venv-requirements.txt
venv_pip = $(venv_python) -m pip
venv_python = $(venv_dir)/bin/python
_venv:
@[ -d '$(venv_dir)/' ] || set-x mkdir '$(venv_dir)'
[ -x '$(venv_python)' ] || { \
set -xue \
rm -rf '$(venv_dir)' \
$(base_python) -m venv '$(venv_dir)' \
}
$(dev) $(venv_pip) install -U wheel pip
$(dev) $(venv_pip) install -U -r $(venv_requirements)
Cheers,
Cameron Simpson <c...@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list
