Getting rid of virtual environments with a better dependency system

[Chris Angelico]

On Thu, Nov 12, 2020 at 10:44 AM Dan Stromberg <drsalists at gmail.com> wrote:
>
>
> 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.
>

Ah, fair enough.

Did you know that, with a vanilla venv, you can actually just run a
Python interpreter from within there, without sourcing anything? Very
handy for automated scripts.

rosuav at sikorsky:~$ mustard-mine/env/bin/python3 -c 'import sys; print(sys.path)'
['', '/usr/local/lib/python38.zip', '/usr/local/lib/python3.8',
'/usr/local/lib/python3.8/lib-dynload',
'/home/rosuav/mustard-mine/env/lib/python3.8/site-packages']

ChrisA