Importing/ exporting from poetry in pip format.

Hi Sébastien, Now the poetry works great as a package manager (I’m happy to use it!). So, I think, maybe it’s time to revisit export/import to requirements.txt for the projects that can’t rely on poetry being installed on the target environment, but still wanted to be managed by poetry (some people prefer pipenv utility, other people use plain pip, etc). Also, I’m considering use cases when you need to import the pip list of the existing packages to poetry.

The export workflow looks pretty simple: you just export the requirements, similar to how “pip freeze” does (now this can be only done with poetry run pip freeze ) , or add some option, maybe the good syntax is poetry show --requirements. A proposed implementation is here: https://github.com/sdispater/poetry/issues/100#issuecomment-409807277

As for the import workflow, right now the challenges are:

1. requirements.txt format is different from one that poetry uses
2. “poetry add” might break if one of the dependencies won’t install

I consider the following command line options (naming can be different, of course): poetry add --requirements requirements.txt and poetry add --pip poetry>0.10, poetry add --pip lxml<4.2.6 poetry>0.10 (Or maybe you can just support this format without this option) I’m not sure how complex is to handle properly the pip format, but even the minimal support would cover 99% of the requirements: “package”, “package{comparison op}version”. They now work if you add a colon, like this: “package:{comparison op}version”. So I believe it’s easy to support those – that would be a great help! Also, to prevent poetry add from breaking, I would consider adding: poetry add --save which only saves the updates, then, poetry add --lock which updates the lock file, but doesn’t install the package(s) (similar to how poetry update --lock). I would also add poetry remove --save and poetry remove --lock to have the inverse operations. I would also change poetry add behavior to ignore already added requirements (though a warning might be displayed). Otherwise after poetry add package1 package2 package3, if it breaks at package2 you not only need to change package2 options but also remember to remove package1 from the list – otherwise, you’ll get a “Package package1 is already installed” error. Currently I have to use the following script to import the requirements from a file: cat requirements.txt | perl -pe 's/([<=>]+)/:$1/g' | xargs -n 1 echo poetry add Exporting the list is also non-trivial now, so it’s great that pip freeze works fine.

I believe these features might significantly increase poetry adoption speed.

• I have searched the issues of this repo and believe that this is not a duplicate.

[danihodovic]

As for importing, I am not sure this is a direction I want to go in. I understand that if you have a lot of dependencies this might be somewhat a painful process but I don’t want to blot the CLI for cases that can be handled by hand or via a simple script.

@sdispater I think it would increase the adoption rate if an import command was built into Poetry. I like using Poetry, but having to do manual work (or rely on scripts) when moving every legacy project to Poetry is an adoption barrier.

If export already exists, I think it’d be consistent in the CLI if import existed as well.

[floer32]

one-liner import script

Just quoting piece of OP @buriy 's post, in freestanding comment.

the one-line import script I provided

👇

Currently I have to use the following script to import the requirements from a file: cat requirements.txt | perl -pe 's/([<=>]+)/:$1/g' | xargs -n 1 echo poetry add