[DESIGN] Refactor away from the single-script design

[VannTen]

@frenzymadness

While looking at #232 and others, I had some thoughts on possible refactoring. However, not being super familiar with the usage of micropipenv (yet), I was wondering if that was a reasonable direction:

• Refactoring the single script micropipenv.py into a proper python package, exposing the cli tools from the project.scripts section in pyproject.toml. On the cons side, this would prevent the "No installation" use case described in the README. Is that feature used significantly ? On the pros side, this would gave us the possibility to have a clearer structure, and more easily add stuff like #232

Thoughts ?

[frenzymadness]

Good question. I have no idea how many users use the "No installation" feature but because this tool is designed for containers I'd say that the number of users might be higher than 0.

To be 100 % honest, I lack the motivation to implement support for pdm because I see that our support for Poetry isn't perfect, see #33 and #187. Moreover, I personally don't use Pipenv or Poetry in my projects so it's kinda hard for me to track all the news in these projects and then implement them here so adding pdm I don't know and don't use will make the maintenance of micropipenv more complicated for me.

But I don't want to block the development of micropipenv. So if you want to implement the support for pdm and you think that converting micropipenv from a single file to a proper Python package will make that easier, I'm fina with that.

[fridex]

I would kindly also vote for keeping this as a single script app. The tool can still be used as a Python package even though it is a single file script. It helps a lot to just download a single file and run it (dirty in some cases, but works for testing apps and so).

[VannTen]

What use cases have you in mind where

curl -o micropipenv.py ...
python micropipenv.py <args>

is easier than

pip install micropipenv
micropipenv <args>

? (Why not, but this comes with some cons on the maintainability side, so I'd like to see more clearly and concretely the advantages)

[fridex]

Something like this (just to have a container ready):

FROM quay.io/fedora/python-311

WORKDIR /app/

COPY app.py Pipfile.lock /app/
RUN curl https://raw.githubusercontent.com/thoth-station/micropipenv/master/micropipenv.py | python3 - install

ENTRYPOINT ["python3", "app.py"]

Also when using virtual environments - I tend to avoid having Pipenv/poetry if not adjusting requirements.