Look for requirements.in when converting

pip-tools uses requirements.in like Pipfile, so that requirements.txt is like Pipfile.lock. When both are present, and pipenv wants to automatically create the Pipfile, it should use the requirements.in file instead of requirements.txt.

[bittner]

Mutual support would be cool, so that either tool could (at least) import, (maybe) auto detect, (optionally) convert, and compare + align with the other files. So, they could be used interchangeably, at developer’s discretion.

Personally, just to give an example motivation, while I see pipenv to be the right path down harmonization with other languages and technologies, I do like the single-line simplicity of requirements.txt (and requirements.in) that pip-tools is handling more.

[frankier]

Yeah, I don’t see mutual support as a useful feature or desirable in terms of the scope of either tool. Round tripping is messy. Pipfile seems strictly better to be so the migration path should be towards it (it’s being standardised, so it’s possibly you might use it with a tool other than pipenv in the future).

However, it would be cool if requiements.in projects could be migrated more smoothly.

It shouldn’t be too hard since half of what’s need can be done already quite easily:

$ mv requirements.txt requirements.txt.lock
$ mv requirements.in requirements.txt
$ pipenv install

All that’s missing at that point is the lock file should be based upon requirements.txt.lock instead of relocking the requirements. Even just doing something equivalent to the above (while issuing a warning about discarding locked versions) could be useful.