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/6d2df38acf21085e601e02bfc029c77d8c485285/trunk/PKGBUILD#L49
[2] 
https://archlinux.org/packages/community-staging/x86_64/python-sqlalchemy1.3/

Regards,

Chih-Hsuan Yen

Attachment: signature.asc
Description: PGP signature

Reply via email to