Hi Greg, thanks for your input. Regarding this: > I find the choices that give rise to this approach to be problematic. > Containers are a useful device for someone to choose, but if people feel > they have to use a container, that's a clue that the situation is > troubled.
> I suspect you are running into packages which require an exact > dependency, rather than the proper approach of having a minimal version, > trying hard to not to raise that without cause, and adapating to any > released version >= the minimum. Some upstreams, influenced by > language-specific packaging tools, take the approach that their package > is the most important thing in the world and therefore it's ok to insist > on exact versions. > So far, it seems that qgis does very well on not being unreasonable > about dependencies (as long as gcc 12 turns out to be ok; see below). If the QGIS repo is good at managing its dependencies in a way that limits its impact on the rest of my system - that's great. The problem is that any other repo could manage its dependencies differently. Over the past year I've probably worked across 50 different repos, many of which I do not maintain and cannot manage their dependencies. If I don't attempt to isolate each project within Conda, containers, or a VM then I am at risk of surprise breakages from what should be unrelated repos. In any repos that I do maintain I provide a containerised option whenever possible to ease the lives of other contributors. > However, I think it's important for it to be reasonable to build without > containers. I agree - I'm not suggesting QGIS should _only_ build and run in a container, but I think the option of building and running in a container could be better supported and I'm happy to contribute to that effort if others also want it. Tom _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
