I think we’re talking past one another here. You don’t need to write a program in a compiled language to have an artifact that you ship to end users that doesn’t depend on an already installed Python. Saying or implying that you do is simply incorrect.
posy.
It’s funny that you’re calling out pubgrub for maintainability and error messages, when the pubgrub library in rust hasn’t had a release in almost 2 years or a commit to their dev or release branch in almost a year, and which I think can’t even fully implement PEP 440 version specifiers.
This statement doesn’t make any sense. Whether or not you set a clear scope doesn’t impact whether or not that scope solves the whole problem or not. The original distutils-sig post that Nathaniel made years ago and referenced again spoke to the fact that part of the problem with the slew of existing tools was that they defined their scope too narrowly, and in doing that failed to make a complete, coherent solution from beginner to advanced.
My assertion is that packaging things for distribution to end users is also part of the packaging story, because well it is, and it’s one of the most chronically underserved parts of our packaging story, and if you want to design “the whole elephant” as it were, you have to also design for that.
I certainly agree that posy has a lot of new, very interesting aspects to it, and by tackling a larger share of the problem (albeit not the entire problem), it has the ability to create a more coherent solution. I just think think it’s stopped short.