Export command

[sdispater]

Pull Request Check List

• Added tests for changed code.
• Updated documentation for changed code.

This PR introduces a new export command that can export the lock file to alternative formats. Currently only the requirements.txt format is supported.

This will help the transition especially for systems and tools that only understand a requirements.txt file.

[etienned]

Bonjour Sébastien,

I'm glad you've worked on this feature. In my spare time I was working also on this feature. It was almost finished, I just needed to add more tests before sending you a pull request. But now it's too late!

I've compared your code with mine and many things are the same but their's also some differences. You can check my code here. Here are the major differences I can see:

1. Your code checks that the lock file is existing and up to date, excellent!
2. Your code already support different export formats, mine doesn't but it was in my plans.
3. My code support specifying a path and/or name for the requirements file. The default is the same as yours, next to the pyproject.toml file.
4. Your code always output git packages with the '-e' flag. Mine never put this flag. For my use case, using the requirements file when buiding Docker images, I prefer to not use the '-e' because those packages will never be edited in the Docker image. Maybe this could be configurable?
5. Your code always put the 'egg' part in git packages. In my code it's configurable. This point is partly related with the previous one.
6. With my code, for git packages, it's possible to specify if you want a tag or a hash.
7. Your code supports file and directory package types. Mine doesn't.
8. Both codes permits to specify if you want the dev dependencies but, in your case, your outputting the dev dependencies in the same file as the non-dev one. My code output only dev dependencies and in an other file (requirements-dev.txt). I think this reflect more how peoples work with dev requirements, but I could be wrong.
9. My code output also markers (ex.: python_version >= '2.7').

That's mostly that. The features that are in my code and not in yours that I wish the most you will add are the points 4, 8 and 9.

I also worked on a feature I was definitely not sure it was a good idea: autoupdating of requirements.txt and requirements-dev.txt files when the lock file is modified. You can check this code here. One of my problem with this is that the code need to deduce some settings (tag and egg) from the existing requirements files and it it's not possible to do that correctly every time (when there's no git packages already in the requirements files).

Feel free to do whatever you want with my code and ideas (ignore them, borrow from them, etc.) and thanks for your work!

[yggi49]

While I fancy the feature per se, I don’t like the hard coded output file name.

What about doing it in the traditional Unix command style, i.e., printing to stdout by default, thus giving the user the possibility to redirect the output to a file, or pipe it into another command for further processing?

[yggi49]

What about doing it in the traditional Unix command style, i.e., printing to stdout by default, thus giving the user the possibility to redirect the output to a file, or pipe it into another command for further processing?

Following up on this one, I have started to work on a PR; see #1035.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.