3

I have created a collection of Python scripts, to be used as tools in our dev group. The scripts have dependencies, such as requests and flake8 (this should technically be under dev setup, but whatever).

I have created a setup-dev.bat file, with the idea of being a "first-use" setup.

python -m pip install --upgrade pip --user
python -m pip install --upgrade virtualenv --user
python -m venv .env
call .\.env\Scripts\Activate.bat
python -m pip install --upgrade pip --user
python -m pip install --upgrade virtualenv --user
pip install .

The idea is:

  1. Install and/or upgrade pip on the system

  2. Install and/or upgrade virtualenv on the system

  3. Create a virtual environment .env

  4. Activate it

  5. Upgrade the pip and virtualenv under it (not sure if this makes sense at all)

  6. 'Install' the scripts - most importantly, this install the dependencies

Now the scripts are ready to use and their dependencies are contained within .env. The idea is - if/when those scripts get distributed to the higher environments for Ops to run, I don't want to pollute their environment with my dependencies.

I should point out that those tools will never be distributed over pip or any other system, they are for internal use within the company and will be hosted on a source control, or emailed to Operations with execution instructions.

Now my questions:

  1. Does this even make sense?
  2. Have I unintentionally created a dependency on Windows? In step 4 above I should probably run just \activate instead of the .bat? I guess the .env depends on the host system and would have different contents under a different OS? Which script do I have to call to activate the environment in most OS-agnostic way? The activate, the ps1 or the .bat?
  3. After the users of my scripts have set it up for first time, I guess they should be educated that if they want to run the scripts, they'd first have to run .env\Scripts\activate? Is there any way to semi-automate this, make it more obvious or fool-proof?
  4. Why do I get You are using pip version 19.0.3, however version 19.3.1 is available. as a result of my pip upgrade command?!

Edits:

  • I've changed python -m pip install --upgrade pip --user to python -m pip install --upgrade pip and this got rid of the error. I guess installing "for the user" under the venv doesn't make sense anyway.
  • I got rid of the virtualenv steps, per the comment below
  • Changed pip install . to pip install -e . to ensure that the scripts (some of which act as configurations) are still editable.

I feel like I am progressing, but I am confused about the lack of posts around such setup and it feels like I am doing something wrong.

hyankov
  • 4,049
  • 1
  • 29
  • 46
  • You should just create the env with the latest pip version from the get-go - see accepted answer on [Control the pip version in virtualenv](https://stackoverflow.com/q/21099057/674039) about that. And you don't need to install `virtualenv` at all these days, because of stdlib [`venv`](https://docs.python.org/3/library/venv.html). – wim Jan 11 '20 at 19:38
  • oh, OK, I will get rid of the `virtualenv` steps then – hyankov Jan 11 '20 at 19:39
  • 1
    Sounds like you want something like [pipenv](https://github.com/pypa/pipenv). – jordanm Jan 11 '20 at 19:40

1 Answers1

1

You could bundle the scripts in a wheel file (read about entry_points here) that can be installed via pip (i.e., pip install bundle.whl; see this). With this approach, the dependencies will be part of the wheel file and pip will automatically install the dependencies when the wheel file is installed.

--user flag to pip will install the scripts in a location local to the user as determined by the user scheme. So, if you are fine with the scripts "polluting" a user's local installation, then virtualenv is not needed.

Venkatesh-Prasad Ranganath
  • 1,776
  • 11
  • 19