Hello, those modules are available in python when doing “from max import driver” (as an example). Since they’re python files, they can be read in the venv. Currently when trying to find out how something work, I use the docs but also use my IDE to look in the .venv where I can read the source files. It would be nice if the source files were available here: modular/max at main · modular/modular · GitHub .
If there is some pushback: Obfuscation is not a concern since we can already read those files in `.venv/lib/python3.11/site-packages/max/{driver,dtype,….}`. Jump to source works in the IDE, so those files are already publicly available. If Modular is not ready to accept contribution on the subject, feel free to say it in the CONTRIBUTING.md and we’ll just consider those files read-only like we did for the kernels when they dropped.
When talking with my colleagues about this lib, I don’t always have my IDE opened to show the source code. So we go to gihub, but it’s annoying that some modules can be seen from github and for some others we have to open our IDE.
I don’t have a timeline but I believe this is planned. We’re aware it’s silly to have the Python source distributed in plain form in the wheel not be in the open source part of the repository. Some of the packages backed heavily by native code (which is harder to open source in the short term, though I think is still planned longer term), this was intentional for (e.g. driver, engine), but some other ones (e.g. experimental, interfaces) they were intended to be open source but the Copybara configuration (which we use for mirroring parts of our internal repository to the public repository and vice versa) was not updated – call that a packaging mishap, I guess. I believe we’re planning to move some stuff around in our internal repository to make this more consistent. Targeted fixes would be possible in the mean time but I believe we’re instead planning to wait for these moves so we can hopefully fix this issue “for good”.