Chris Sewell

> Even if they did do some environment management, they still need all of the packages to execute their content installed in the same environment as Jupyter Book, right? Well,...

Heya, > as @choldgraf noted if any dependency starts to rely on a dependency that you don't support, no one can install JupyterBook That's incorrect, you can't "start to rely...

> I couldn't install a dev version of any of the dependencies because they were pinned so tightly. Can you give a dev version of what you were trying to...

> I think another cost for the end user that isn't mentioned is the inability to get bugfixes in the dependencies if they land in the newer versions. Pinning to...

> At some point NumPy releases 1.13 and that breaks your package's version 4.1.0. So you go back and release a 4.1.1 with an upper pin numpy >=1.3,

> Why would the solver install 4.1.1 and numpy 1.12, and not just 4.1.0 and numpy 1.13? Which is exactly what the "Backsolving is usually wrong" section of https://iscinumpy.dev/post/bound-version-constraints/ explains,...

> Because the user would be upgrading your software and the package manager solver tries to give the newest possible versions of all dependencies. Why is 4.1.0 + 1.13 not...

Just want to clarify here, I am not advocating for every package upper pinning, I see the arguments for libraries. But I'm stressing, there is a big difference between something...

> so they also need to have all that software installed along with jupyter book in the same environment because jupyter book I've already explained why this is not actually...

> Setting up different virtual environments is a tough concept for average users too. Which is exactly why I said we should make it easier 😉