Non IDE development strategy - what do others do that's fairly simple?

[Cameron Simpson]

On 29Jul2020 11:20, Chris Green <cl at 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 <cs at cskk.id.au>