Support poetry

[MichaelAquilina]

No description provided.

[rnc]

It would be great if this could be supported as well. Currently poetry conflicts leading to e.g.

poetry shell
Spawning shell within /home/rnc/.cache/pypoetry/virtualenvs/commitizen-py3.7
Deactivating: commitizen-py3.7
_default_venv:6: command not found: deactivate

[rnc]

@MichaelAquilina From looking at the changes in branch next it seems there is different behaviour depending on whether pyproject.toml is used or setup.py ; i.e. the README says it will by default install in editable mode but it seems that if pyproject.toml is being used then it will install by default in full mode? Perhaps at the very least this should be documented?

For poetry specifically, it would be useful if it could generate the setup.py (poetry/issues/761 ) but that currently isn't supported and it also doesn't support inheriting system site packages (poetry/issues/1393). Using the suggestion in 761, I adopted create_setup.py and use that before running mkvenv --system-site-packages.

[MichaelAquilina]

the README says it will by default install in editable mode but it seems that if pyproject.toml is being used then it will install by default in full mode? Perhaps at the very least this should be documented?

You are correct on both counts. Based on the discussion for the original merged PR it seems like installing in editable mode is not possible. You are right that this should be documented though. Would you like to open PR yourself and take a go? (Happy to do it myself but only seems fair to give you the opportunity since you found the issue :) )

Unfortunately my knowledge on poetry is very limited (I've only used it once, more than a year ago) so there might be mistakes in the implementation.

For poetry specifically, it would be useful if it could generate the setup.py (poetry/issues/761 ) but that currently isn't supported and it also doesn't support inheriting system site packages (poetry/issues/1393). Using the suggestion in 761, I adopted create_setup.py and use that before running mkvenv --system-site-packages.

Considering my lack of knowledge in this area. Could you elaborate with step by step examples?

PS: This is partly the reason why the next branch has not been released yet - I still need to do some manual testing to feel confident enough to release it.

[rnc]

Tagging @wouterweerkamp who added the pyproject.toml and knows more about it :-)

[rnc]

I'd be happy to make a PR but I think a design should be chosen first.

Having had a bit of an initial read into pyproject.toml/poetry I think I see the difference now. What I haven't yet dug into (had time to!) is how pip with pyproject.toml supports editable mode and whether it requires (currently?) a setup.py as well?

As for poetry, one option might be to say if [tool.poetry] exists within pyproject.toml then generate the setup.py and use in editable mode otherwise just create the venv and print a warning?

[MichaelAquilina]

As for poetry, one option might be to say if [tool.poetry] exists within pyproject.toml then generate the setup.py and use in editable mode otherwise just create the venv and print a warning?

I'm afraid that generating artifacts without the users permission might be confusing. While its not consistent behaviour with the default (i.e. editable mode by default), I think I prefer it to the alternative.

Having had a bit of an initial read into pyproject.toml/poetry I think I see the difference now. What I haven't yet dug into (had time to!) is how pip with pyproject.toml supports editable mode and whether it requires (currently?) a setup.py as well?

I'm afraid I'm not sure of this myself :( I should have probably dug more into it before merging the change into next - but at least it can still be changed before releasing it to master if needed.

[rnc]

As for poetry, one option might be to say if [tool.poetry] exists within pyproject.toml then generate the setup.py and use in editable mode otherwise just create the venv and print a warning?

I'm afraid that generating artifacts without the users permission might be confusing. While its not consistent behaviour with the default (i.e. editable mode by default), I think I prefer it to the alternative.

Yes I think you're right. How about a configuration option? That way, the users have to set it in order for the generation to proceed.
If we did go down this route then I think rmvenv should remove any generated files?

Another possible method to keep it consistent is just to create the venv and output a message to set the configuration option (as per 2 on #117 (comment) )

Having had a bit of an initial read into pyproject.toml/poetry I think I see the difference now. What I haven't yet dug into (had time to!) is how pip with pyproject.toml supports editable mode and whether it requires (currently?) a setup.py as well?

I'm afraid I'm not sure of this myself :( I should have probably dug more into it before merging the change into next - but at least it can still be changed before releasing it to master if needed.

:-)