Re: [aur-requests] [PRQ#26744] Deletion Request for octoprint-venv
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. 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. [1] https://github.com/archlinux/svntogit-community/blob/6d2df38acf21085e601e02b... [2] https://archlinux.org/packages/community-staging/x86_64/python-sqlalchemy1.3... Regards, Chih-Hsuan Yen
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/6d2df38acf21085e601e02b... [2] https://archlinux.org/packages/community-staging/x86_64/python-sqlalchemy1.3...
Regards,
Chih-Hsuan Yen
participants (2)
-
Chih-Hsuan Yen
-
Jake