add develop option for git dependencies

[shenek]

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

Feature Request

It would be nice to add develop option for git dependencies.
So it would work in the similar way as path dependencies.

Rationale

Currently there's no way to specify that git dependencies should be installed in non-editable mode (develop=false). So all git dependencies are installed in develop / editable (pip -e ...) mode.

Now imagine a situation that you are e.g. installing the dependency from your private repository using a tag (always points to the same commit). In this case you don't want that dependency to be installed in develop mode (the source directory is not going to change). You want to use install instead of develop.

[kalemas]

It would be helpful as i plan to use contents of virtualenv's site-packages folder to vendor dependendencies.

Also it look like develop does not trigger build process so i getting broken packages. Maybe it is problem with my dependencies, may be develop work that way - i did not figured this out yet.

[kalemas]

so develop trigger build_ext that my dependencies do not provide at all...

[kalemas]

Isn't poetry virtual environments ephemeric? If so I don't mind it should be called "develop", it look like internal optimization and development mode should not be enabled when installing from commit/tag at all. Tags would change but it is publisher's responsibility.

[kalemas]

My further meditation lead me to that git branch dependency is something would harm, environment will not be reproducible if branch tip changes.
Installation inside virtual environment and enrty in poetry.lock should always point to commit, updating branch dependency would be laid on poetry update.

[tueda]

I also hit this issue in the sense that git dependencies do not trigger any of their build processes.

Moreover, it seems that they are cloned without the --recursive option, so broken when they contain submodules. (I see the submodule directory is empty; I must have encountered an error if the build process ran during poetry install.)

[jonykalavera]

I ran into this problem because our current pipeline first creates the virtualenv in a release server, then makes it relocatable and then copies it to the production servers. The problem is that the editable packages create an egg-link with an absolute path that does not match the end location. so this breaks all our private-repo dependencies.

[dazza-codes]

Apparently this was fixed already in python-poetry/poetry-core#23 and released in an earlier 1.0.0 alpha, but it doesn't seem to work in release 1.0.5 at the moment. Is there some kind of rollback or regression on this feature?

$ poetry --version
Poetry version 1.0.5

$ poetry update

[RuntimeError]
The Poetry configuration is invalid:
  - [dependencies.xxx] {'git': 'ssh://[email protected]/xxx/xxx.git', 'tag': '0.1', 'develop': False} is not valid under any of the given schemas

Can this feature get a rollout for a poetry self update on a 1.0.x release?

[dongho-jung]

@dazza-codes that's what I think, too. the poetry-core already fixed it. However, when would it be merged with poetry? I think this is a quite big issue for some people like me who uses private git repo as a private python package registry.

[ahobsonsayers]

Is there any update to this? The pyproject.toml of poetry implies that poetry is currently using poetry-core 1.0.0a9 which should have this feature but it still is not working as of 1.0.10. Is there something missing that needs to be done for this feature to become available? Im willing to make PR if required.

[abn]

@ahobsonsayers 1.0.z does not use poetry-core. Please try 1.1.0b2 pre-release of 1.1.z.

[ahobsonsayers]

@abn Thanks for pointing this out, I updated poetry to the latest preview version and the develop flag now works perfectly 😁

[github-actions]

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