Three Dollar Quill

I haven't made any dramatic breakthroughs on the last test I have. I'm just going to try to lay out what I know.

I am creating a wheel at... wait. I have a suspicion about what's going wrong. If I'm failing to properly replace the wheel tags...

Okay, I've done something less brittle. Wish me luck! Or don't, the test will run well before I need to publish this.

Hm, didn't work, let's see what happened...

It's still hard to figure out what's going wrong. It looks clear that it's possible for the URL constraint code I added to just not fire. Which is troubling. The way that this would happen that makes the most sense to me is that the constraint isn't being added. Why could that be...

Okay, there's a bunch of code that I added, and all of the other tests pass, so the problem is either specific to what the test is asserting, or how the test is written. I'm going to go over the test in excruciating detail.

• I create a wheel for "dep" at version 0.1.0.
• I attempt to change the wheel tags. I'm not sure that I'm doing this correctly, but I'm not seeing the expected failure from doing this wrong. Nevertheless, I should work on doing it right.
• I create a constraint file that points to the changed(?) wheel.
• I create a subfolder for use as the find-links target, because I'm unsure of the behavior of find-links, and I can work around that uncertainty like this.
• In that sub-folder, I create wheels for "dep" at 0.2.0, and "base" (I know these names aren't good) at 0.1.0 and 0.2.0. 0.2.0 of "base" depends on "dep".
• I attempt to install "base" using the constraints file.

The buggy behavior that results is kind of special, because instead of just "what I expected" and "what happened", there's:

• What I expected: version 0.1.0 of "base" is installed, and "dep" is not installed
• How I expected it to break: 0.2.0 of "base" and 0.1.0 of "dep" are installed
• How it actually breaks: 0.2.0 of "base" and "dep" are installed

So, the first version corresponds to "knew about the constraint, generated no candidates because it didn't match the installation platform, backtracked to lower version of base". The second version corresponds to "knew about the constraint, generated a candidate because I didn't set the wheel tags properly, installed latest base". The third version, I can't be as sure of, because it happened outside my head, but it looks like either the constraint didn't get populated, or the constraint failed to reject a completely different path.

The latter option, I'll try to check, because I wrote the rejection code and it's not completely trivial. ... It is pretty close to trivial, though, and it sure looks like it should be capable of distinguishing the paths at issue.

All the same, the only way I can see to pin this outside my code is to suppose some form of filtering step that's stopping the constraint from populating, and that doesn't seem to exist.

At the same time, I have tests passing that require the constraint logic to fire under some conditions.

So, I'm going to want to fix my wheel generation just because it's really doubtful that what I'm doing currently works. However, once I'm satisfied with that, I'm going to have to ask for help, because I don't think that's going to fix it, and something is really wrong. I'll try to work on the first part while this publishes.

Good night.