While we are here, I think it could be a good idea to do a small refactor and extract some base Exporter class which all export formats would inherit from. Without it, we can quickly fall into a hellhole of messy code when we try to add yet another format to the mix. That however could be out of scope and might be better suited as a separate task.

While we are here, I think it could be a good idea to do a small refactor and extract some base Exporter class which all export formats would inherit from. Without it, we can quickly fall into a hellhole of messy code when we try to add yet another format to the mix. That however could be out of scope and might be better suited as a separate task.

We used to have something like that -- but for now, this simpler approach with method dispatch looks preferable to me. An ABC exporter that each format extends definitely makes sense if we ever go beyond pip's two 'txt' formats (e.g. a Pipfile.lock or something).

I've pushed two commits that amend your code to rearrange the exporter more in-line with the prior code, as well as to add a test for editable exports in constraints.txt format properly throwing

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

No Coverage information
0.0% Duplication

Thanks for helping to see this through!

(Sorry for my lack of editable mode tests. I swear I tested a setup similar to what you did and it didn't work for me but I must have been mistaken.)

Thanks for adding this! I ran into this exact issue today and was very pleased to see this already addressed 🎉