[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 2020-07-29 at 11:20:42 +0100,
Chris Green <cl at> wrote:

> I have a few python programs that I have written which I need to do
> some fairly extensive changes to (to get from gtk to gobject and to
> move to Python 3).  This is on a Linux (xubuntu 20.04) system.  I use
> the command line to do just about everything (even though the program
> is GUI!) and so I tend to edit in one window and test in an adjacent
> window on the same screen, I don't find GUI development environments
> comfortable.

+1.  All of it.  Except that I'm on Arch rather than XUbuntu, and our
definitions of "one window" and "adjacent" likely vary.

> However with this more major change to do I really need a
> 'development' copy of the code as well as the live working copy as
> it's likely I will take a few days to do the changes (as in an hour or
> so each day over some days) and I need the ability to use the program
> meanwhile.

Given that you develop in production, you might be better off thinking
of the Python3 version as a new program rather than a simple maintenance
upgrade of the existing one.

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

> 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'.
> There's also the issue that I'm moving code from Python 2 to Python 3
> so which virtual environment should I use?

All my development takes place under ~/src, which is mostly under source
coontrol, but not under virtual environments.  When I'm satisfied, I
"release" or "install" to ~/bin and/or ~/lib by copying the relevant
file(s).  Too many years of work-related production environments being
unavailable or unsuitable for development (unless you squint just right
at the times I used to patch machine code on a hardware emulator).

HTH, YMMV, etc.