<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<div class="moz-cite-prefix">On 26.07.21 14:17, Chih-Hsuan Yen
wrote:<br>
</div>
<blockquote type="cite" cite="mid:YP6nw7Vp5WcFmad9@PC951">
<pre class="moz-quote-pre" wrap="">On Tue Jun 29 09:15:31 UTC 2021, Jake wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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...
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Sorry I missed this message and hit the deletion button too early. I
first restore the package on AUR.</pre>
</blockquote>
<p>Okay, good.</p>
<blockquote type="cite" cite="mid:YP6nw7Vp5WcFmad9@PC951">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
I know about these tricks and have used them for other packages. <br>
<p>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.</p>
Creating extra packages to pin versions works of course, the problem
is just the huge amount of runtime <span class="pl-c">dependencies:</span><br>
<a class="moz-txt-link-freetext"
href="https://github.com/OctoPrint/OctoPrint/blob/1.6.1/setup.py#L25">https://github.com/OctoPrint/OctoPrint/blob/1.6.1/setup.py#L25</a><br>
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.
<p>
</p>
<blockquote type="cite" cite="mid:YP6nw7Vp5WcFmad9@PC951">
<pre class="moz-quote-pre" wrap="">
[1] <a class="moz-txt-link-freetext" href="https://github.com/archlinux/svntogit-community/blob/6d2df38acf21085e601e02bfc029c77d8c485285/trunk/PKGBUILD#L49">https://github.com/archlinux/svntogit-community/blob/6d2df38acf21085e601e02bfc029c77d8c485285/trunk/PKGBUILD#L49</a>
[2] <a class="moz-txt-link-freetext" href="https://archlinux.org/packages/community-staging/x86_64/python-sqlalchemy1.3/">https://archlinux.org/packages/community-staging/x86_64/python-sqlalchemy1.3/</a>
Regards,
Chih-Hsuan Yen
</pre>
</blockquote>
</body>
</html>