Story for tools ecosystem

[kfsone]

It's often said that Python has a great ecosystem of tools, but I ask: Which ones? Do you mean pip, conda, pyenv, pipenv, virtualenv, setuptools, ... ?

Put another way: What is the command you run after git clone...? If I have just pip installed package X, what now? Has anyone else noticed how often help(pypi-package-name) results in a list of sub-topics that aren't accessible via the bleedingly-obvious help(package.subtopic)? or the number of reddit/stack/quora posts asking what commands came with a package they installed?

ChatGPT provides a great way to amortize tribal knowledge about such things, and so I recently did a few experiments to have it walk me through creating a python application with a few dependencies. Emphasis on configuring the package from the start for collaboration.

Experience with other languages (C++/CMake, Rust, Golang, etc) suggests that these days IDEs like VSCode enable us to download a package and go. But with Python?

What ultimately confused me was the amount of time GPTs instructions were about additions to the README. Symptoms of a fragmented and unplanned tooling ecosystem.

Getting a CTO to read past the emoji file extension is going to need some serious selling, and a robust, well integrated story for Mojo projects might go a long way - something that IDEs can actually and readily speak to.

Might I suggest a ".mojo file" at the top of any given tier of a project to house settings/config, and explicit call outs in the mojo spec to additional files such as ".editorconfig" etc? It might also behoove the project to have a specification for additional tooling, such that tools like tox / linters / etc, can have well defined roles that IDEs/build systems can reason about.

[ksandvik]

The poetry tool (Python packages) tries to do the same thing as cargo for resolving dependencies, so you could check that one out. But I agree, having a rock-solid packaging tool or a universal tool like cargo that includes packaging would be neat.