Three Dollar Quill

All right, what did I find yesterday? I found two issues. One was around installing the package from the current directory. Something was going really screwy there as a result of other commands running while pip was reading the directory contents. I still feel like there was no call to try to install a package from a SQLite database, but it is what it is. The other was that something ended up talking about the paths to ~ip, which appears to not be a thing.

I can sort of understand the former, so I'll try to figure out a way around it.

Okay, let's see what makes the most sense... If I do a flit build, then the build artifacts will be in the dist folder, under a name based on the version, which flit currently does not have a command to expose. If I'm willing to compromise on my vision for MOTR, I can build the artifacts out of band and use stat data to find the newest wheel. Are there any alternatives? Well, I may not know the path to the file, but I know the path to the directory. Can I create an index to add to the install command, with the caveat that this definitely needs to install third-party packages, and that there is a version on PyPI that I don't want to install... I mean, it looks like --find-links would sort of work with this, except that it would be kind of brittle. Like, I couldn't run tests against an older version than the current release, and that's not acceptable from a maintenance perspective. And there are enough sequencing issues even with just using dist that I can't be too comfortable with it.

So, hm, using a direct path or URL to the archive looks like the only way to handle this. But I think I can still write this in a way that doesn't require determining the version ahead-of-time. (I want to avoid this because running flit build when I do motr --list-targets seems unexpected.)

• Install flit in a venv
• Run flit build --format wheel
• Inspect dist for the newest file, and write the path as a file url in a requirements.txt type file (This is a custom Action)
• Use the path to the requirements file as an Input for the various pip installs, instead of .

I think that should take care of a bunch of issues, but I still don't know what's with the other error. The way it's talking about __pycache__ directories under src has me hoping that this is somehow also a sequencing issue with running flit through pip, or at least that it has something to do with it.

(Scaling this solution up to my "monorepo-esque" layout would be interesting. I think the most reasonable way would be to replace the third step with a custom action that essentially handles some of the sequencing itself. After every install is completed, then the custom action has to retrieve and collate all of the wheel-related data. It can then store that information in a constraints file. Properly handling this probably also needs a quick parse of the pypyroject.toml file for each project. Or maybe the monorepo-esque layout should just expect the project name to match the package name.)

Anyway, good plans for when I'm ready to get back into this. I've got a few other things I want to take care of tonight, so I'm going to wrap this up now and get to work on those.

Good night.