Magicimport.py: Python code that fetches its dependencies without complaining

> You can even specify a version number

Sorry to be sarcastic here but wow, you mean I can even make sure that my code will not break at an arbitrary point in the future, when my dependency inevitably introduces a breaking change? Fantastic.

I understand that installing dependencies is a bit of a hassle. But really, once you have done it twice it takes seconds. And I would not want a mechanism that fetches dependencies as a side effect of my app running. I want to know what's going on when my app runs. The fewer moving parts, the better. Often, it's hard work to achieve this simplicity. But, at least in my experience, it pays off.

You shouldn't use this in a production web service--and the author says as much in the README--I think there are some great uses for this code:

1. Demonstrating how the Python import system works. There is a lot of nuance at hand that other programming languages (like C) don't have an analogy for.

2. Creating truly self-contained Jupyter notebooks. Right now, if I want to send someone a working Jupyter notebook, I have to send them a requirements.txt (or, better yet, a Dockerfile) for them to install in a virtualenv. This is too bad, because specifying the dependencies in the notebook itself is better for teaching purposes.

Personally I've been really happy with with pyenv[0].You can install multiple different versions of Python side-by-side and it does a great job managing virtualenvs.

pipx[1] is also pretty good for managing virtualenvs to install applications in but IMHO less so for doing actual development. You can use it to seamlessly install venv'd Python apps or spin up apps in ephemeral environments.

[0]: https://github.com/pyenv/pyenv [1]: https://github.com/pipxproject/pipx

For instance I encountered a python wheel lately that "conveniently" shipped a precompiled .so file. Not only was that a security problem but also did that file not work properly under Ubuntu 18.04.

Compared to R, pythons imports syntax and handling is a god-sent when sharing code, but we still saw a lot of people get stuck after cloning a notebook or dashboard trying to figure out all the dependencies they needed to set up to run it.

Now they just copy the notebook/dashboard and first run configures everything For them referencing both internal and external dependencies.

It’s a small but important difference especially for juniors.

In the future I would love for python just to support something like “import pandas==1.1.3@pypi” and having that automatically do what every python developer who works with virtual envs would do if they saw the “==1.1.3@pupi” in a comment after the import. But then obviously also supporting installs from other sources than pypi.

Famous last words.

it's saved me a world of pain a number of times to have different versions of the same libs installed in different envs

For example if I do glob.glob("*.txt") it's rather obvious that I also wanted to "import glob".

Would definitely recommend Poetry for anything larger, it's been a great experience.

I wrote a script that would try and automatically determine missing packages and their version numbers a while a go: https://gist.github.com/JosephRedfern/ef52916e70497bc9631d6e...

It was a joke rather than a serious tool. Caught import errors and runtime errors and would install pip packages going back from most recent to oldest, until the script under test worked without error. At least, that was the idea —- I never really finished it.

that said, it is an amusing hack to run the virtualenv'd python in a subprocess and then extract the environment vars and inject them into the already running python process.

some of the code could be cleaned up a bit -- e.g. it could be using https://docs.python.org/3/library/tempfile.html#tempfile.Tem... to just ask for a uniquely named temp dir, some of the subprocess invocations dont appear to have error handling, etc.

for my python hobby project these days i only depend upon packages i can install using apt in debian stable. containers for isolation help too.

[1] https://www.infoq.com/presentations/Simple-Made-Easy/

[0](https://www.zdnet.com/article/two-malicious-python-libraries...)

For example, one could replace a python shebang with fades' one and mark dependencies using # fades comments:

    #!/usr/bin/fades
    import dependency # fades

I don't understand why it even uses virtualenv, when venv is a) part of the standard library, and b) the recommended way to create virtual environments in Python.

While the import from __future__ indicates that it's supposed to support Python 2, the shebang line is explicitly Python 3...