[aur-requests] [PRQ#26744] Deletion Request for octoprint-venv

[Jake]

On 26.07.21 14:17, Chih-Hsuan Yen wrote:
> On Tue Jun 29 09:15:31 UTC 2021, Jake wrote:
>
>> If you dislike the general approach of using a venv then just
>> contribute/patch the already existing 'octoprint' (no suffix) package to
>> remove the venv there. Keep in mind that this would break often on
>> dependency updates and therefore will be a lot of patch work. I have
>> tried it for a while and it was just not feasible...
> Sorry I missed this message and hit the deletion button too early. I
> first restore the package on AUR.

Okay, good.

> Regarding packaging difficulties - I understand your situaltion as I
> have met several upstream developers that don't care about the latest
> dependencies at all. Here are some possible tricks that come to my mind:
>
> * Remove upper bounds of dependencies from setup.py. For example, use
>    a sed command to do that like python-moto [1]
> * If API changes in dependencies are too complex to have a fix,
>    create a package with an older version. For example, the recent
>    python-sqlalchemy1.3 [2] for packages that don't support sqlalchemy
>    1.4.
>
> Have you ever tried those tricks? They are not ideal solutions, either,
> but may help on getting away from venv.
I know about these tricks and have used them for other packages.

For all dependencies that respect semver there is usually a reason for 
major version jumps, so patching out the check is not a good idea. 
Otherwise the specification in Octoprint does not cause problems as it 
already allows minor updates. Also I would rather not cause tons of bug 
reports from people using unsupported versions.

Creating extra packages to pin versions works of course, the problem is 
just the huge amount of runtime dependencies:
https://github.com/OctoPrint/OctoPrint/blob/1.6.1/setup.py#L25
Making 1 or 2 extra packages does not cut it here, maybe with 10 (at 
least tornado, flask suite, click) it could work momentarily, but then 
there are still 30 others that increase the likelihood of breaking. In 
the past it never worked longer than a few weeks before it required some 
action/fix again.

> [1] https://github.com/archlinux/svntogit-community/blob/6d2df38acf21085e601e02bfc029c77d8c485285/trunk/PKGBUILD#L49
> [2] https://archlinux.org/packages/community-staging/x86_64/python-sqlalchemy1.3/
>
> Regards,
>
> Chih-Hsuan Yen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.archlinux.org/pipermail/aur-requests/attachments/20210728/0cb79c40/attachment-0001.htm>