Getting rid of virtual environments with a better dependency system

[Dan Stromberg]

On Wed, Nov 11, 2020 at 10:38 AM Chris Angelico <rosuav at gmail.com> wrote:

> On Thu, Nov 12, 2020 at 4:35 AM Dan Stromberg <drsalists at gmail.com> wrote:
> >
> > On Wed, Nov 11, 2020 at 3:00 AM j c <jucaranlu at gmail.com> wrote:
> >
> > > Hello all,
> > >
> > > I don't know if this suggestion is missing some point, or it's part of
> > > something already proposed before.
> > >
> > > In a professional environment, we've came to a point in which most
> people
> > > use virtual environments or code environments to avoid "polluting a
> global
> > > environment".
> > >
> > I think it'd be a good idea to have a directory (hierarchy) for each
> python
> > application, and make pip (or similar tool) download to that directory -
> > and then modify the _application's_ sys.path to include that directory at
> > the beginning.
> >
> > This is what I've done with backshift (
> > https://stromberg.dnsalias.org/~strombrg/backshift/).  It works well,
> > without a need for a virtual environment, while still giving dependency
> > isolation.  But it's not as automatic as I'd like - I've had to manually
> > specify what dependencies to put in the directory.
> >
>
> Can you elaborate on exactly how this is different? When you create a
> venv, it creates some symlinks and such that basically mean you get
> that - a directory for the application, pip installs into it, and then
> when you run that Python binary, it'll automatically have sys.path
> contain the appropriate directory.
>

Maybe it's not that different.

I do get a .../bin/backshift though, which is a bash script that knows how
to start up python on the main module.  So the user need not source
something at install time or at run time.

The install process is ./configure and make install, where ./configure is
Not autoconf, but acts sort of like an autoconf script.