<div dir="ltr"><div>Thanks, Nyall.  When you said:</div><div><br></div><div>
And that's the big concern with approaches like conda. Past experience<br>
with using homebrew for the mac builds suffered this very issue<br>
constantly. It's only since the QGIS mac os build was seperated away<br>
from the homebrew dependancy nightmare that we're seeing stability in<br>
the macos builds... * <br></div><div><br></div><div>I thought you were implying that MacOS was a special case that we can't use conda for (I'm not a Mac user, and don't have experience with homebrew).  In general, I think if we avoid following a "use the latest" policy, conda is a stable tool for multi-platform builds.  The platform-specific problems I ran into involved trying to use the latest and greatest.  Did you experience problems trying conda, or just homebrew?<br><br></div><div>I guess from Matthias' comments, though, your multi-platform build requirements are beyond the scope of what conda can deliver?</div><div>Ari<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 2, 2020 at 5:28 PM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 2 Aug 2020 at 16:25, Ari Meyer <<a href="mailto:ari.meyer@gmail.com" target="_blank">ari.meyer@gmail.com</a>> wrote:<br>
><br>
> Nyall, is the issue here multi-platform builds?  I have experienced problems with conda where the Windows port of a native library was faulty (I distinctly remember netcdf4/xarray last year). It seemed like Windows was the ugly stepchild -- always neglected.  I think it will always be a problem for conda, as opposed to pip, due to the native libraries.  So I think it's fair to document problems with dependency versions on particular platforms and provide workable substitutions, but to trust the latest release seems really dangerous to me.<br>
<br>
Ari -- I think you misunderstood my argument. We're arguing for the<br>
same things, as I also agree that having external agencies who are<br>
completely unaware of the needs of QGIS dictate our dependencies is<br>
dangerous!<br>
<br>
I'm ok with this on the Linux side, because Linux distros have used<br>
this approach forever and have very robust structures in place for<br>
handling these. But in my experience conda and homebrew are really<br>
just "wild west" style proving grounds where anything goes and things<br>
are constantly breaking.<br>
<br>
Nyall<br>
<br>
<br>
<br>
 All of the discrepancies I noted in the above issue had differing<br>
minor or even major versions, implying API breakages:<br>
><br>
> Dependency diffs versus the downloadable Windows desktop versions 3.14.0 and 3.14.1:<br>
> a) gdal:<br>
> Windows desktop: 3.0.4<br>
> conda-forge: 3.1.1<br>
> b) qt:<br>
> Windows desktop: 5.11.2<br>
> conda-forge: 5.12.5<br>
> c) sqlite:<br>
> Windows desktop: 3.29.0<br>
> conda-forge: 3.32.3<br>
> d) postgresql:<br>
> Windows desktop: 11.5<br>
> conda-forge: 12.3<br>
> e) qwt:<br>
> Windows desktop: 6.3.2<br>
> conda-forge: 7.0.0<br>
> f) pyqt:<br>
> Windows desktop: 5.11.3<br>
> conda-forge: 5.12.3<br>
><br>
> Given that, it would be interesting to know if one distribution was significantly more buggy than another.<br>
><br>
> On Sun, Aug 2, 2020 at 12:51 AM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> wrote:<br>
>><br>
>> On Sun, 2 Aug 2020 at 11:02, Ari Meyer <<a href="mailto:ari.meyer@gmail.com" target="_blank">ari.meyer@gmail.com</a>> wrote:<br>
>> ><br>
>> > Matthias, WADR, your statement seems, at least on the surface, to indicate an incredibly fragile process.  How can you possibly maintain stability and reproducibility if the dependencies can be changed at will?<br>
>><br>
>> And that's the big concern with approaches like conda. Past experience<br>
>> with using homebrew for the mac builds suffered this very issue<br>
>> constantly. It's only since the QGIS mac os build was seperated away<br>
>> from the homebrew dependancy nightmare that we're seeing stability in<br>
>> the macos builds... *<br>
>><br>
>> Nyall<br>
>><br>
>> * William's system packages use a different approach, so aren't<br>
>> subject to this comment!<br>
>><br>
>> ><br>
>> > On Fri, Jul 31, 2020 at 2:27 AM Matthias Kuhn <<a href="mailto:matthias@opengis.ch" target="_blank">matthias@opengis.ch</a>> wrote:<br>
>> >><br>
>> >> One thing to keep in mind is that even the main qgis installers/distributions do not have fixed dependency versions. Using downloaded macOS QGIS will have different dependencies than Windows and so will all the linux/*nix flavors.<br>
>> >><br>
>> >> On 7/31/20 7:14 AM, Ari Meyer wrote:<br>
>> >><br>
>> >> @Nyall, that proposal appears to be specific to plugins -- not sure if that's the best place to discuss this issue.<br>
>> >> @Greg: I found that many of the exact dependencies were not even available through the main channels.  So if the QGIS devs compile/build against such versions, I'm not sure there's an easy way to even specify such a conda recipe, unless all those dependencies are also made available somehow.  I didn't expect that those versions would not even be there with the others for the various libraries.  Could this imply that the library developers don't want those versions to be used?  Not sure.<br>
>> >><br>
>> >> As a user and developer, I just want to be sure that if I pull down conda-forge qgis version X that I will get the same effective distribution as contained in downloadable installer version X.  Right now, we are getting a very different set of dependencies.<br>
>> >><br>
>> >> Thanks,<br>
>> >> Ari<br>
>> >><br>
>> >> On Thu, Jul 30, 2020 at 6:44 PM Greg Troxel <<a href="mailto:gdt@lexort.com" target="_blank">gdt@lexort.com</a>> wrote:<br>
>> >>><br>
>> >>> Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> writes:<br>
>> >>><br>
>> >>> > There's a related proposal at<br>
>> >>> > <a href="https://github.com/qgis/QGIS-Enhancement-Proposals/issues/179" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/issues/179</a> --<br>
>> >>> > probably best to keep the discussion on that page.<br>
>> >>><br>
>> >>> Not really about the details of using conda but about the concept:<br>
>> >>><br>
>> >>>   conda's documentation says it runs on "Windows, macOS and Linux" but<br>
>> >>>   qgis also runs on at least NetBSD and almost certainly other BSDs.<br>
>> >>><br>
>> >>>   it seems that to build something, including qgis the requirement is<br>
>> >>>   that the things it depends on are present in some way that is found by<br>
>> >>>   the build.  People can choose to do that however they want, and it<br>
>> >>>   seems funny to me to impose a requirement.   If this is really "let's<br>
>> >>>   publish a conda config file so that people who want to do that can do<br>
>> >>>   less work", that's of course fine, but if it's more "if you don't have<br>
>> >>>   conda then you can't build qgis", that's something else.<br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> QGIS-Developer mailing list<br>
>> >> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>> >> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> >> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > QGIS-Developer mailing list<br>
>> > <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>> > List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> > Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>