search

linkml / linkml-project-cookiecutter

A cookiecutter for linkml projects. An equivalent of `linkml-ws new project-name`.
Creative Commons Zero v1.0 Universal
14 stars 16 forks source link

Installing from a source distribution fails w/poetry-dynamic-versioning #76

Closed nicholsn closed 6 months ago

nicholsn commented 8 months ago

I created a linkml project using this cookiecutter and I'm distributing it via pypi where it is installed using a source distribution. However, I am getting an error from dumani that states RuntimeError: This does not appear to be a Git project.

It looks like the poetry-dynamic-versioning build backend requires the git history to be available but this is not present in the source distribution tarball.

The quick fix appears to be falling back to poetry.core.masonry.api rather than using the dynamic versioning plugin, but I'm curious if there is a known workaround for this issue.

pkalita-lbl commented 7 months ago

Hi @nicholsn sorry for not getting a chance to look at this sooner. I'm a little confused about the order of things here. The poetry-dynamic-versioning plugin is active during a poetry build which would produce a source distribution tarball with the correct version number (based on git history) baked in. What's the scenario where the poetry-dynamic-versioning is being called after the tarball is already created? Or am I totally misunderstanding what's going on?

dalito commented 6 months ago

@nicholsn - Could you try my fix in #88? I don't deploy any model to PyPI myself.

I believe the problem was caused by the way the checkout is made in the action. By default tags are not checked out but peotry-dynamic-versioning needs them to work.

dalito commented 6 months ago

Just re-reading the issue... - From a source install (which is not a git repo) there is no way that the version can be determined dynamically.

It would be nevertheless interesting to know if the action has been producing a correct dynamic versions without #88.

nicholsn commented 6 months ago

@dalito and @pkalita-lbl, thanks for looking into this. A detail I should've included is that I'm using a private pypi (cloudsmith) and an internal github action to publish that's different than the one included in this cookiecutter.

It looks like the source distribution coming out of my internal pypi is the same as what is in source control and that it was not updated with any version info. I think pip is trying to generate the versioning on the fly and that is why dunamai since the git repo isn't present.

Do you think publishing a wheel to pypi would resolve this?

dalito commented 6 months ago

To me it is not fully clear if you build in a git repo/clone with the tag information present. Does git tag give you a list of tags? You could add git tag command to your pipeline and inspect the log.

Do you think publishing a wheel to pypi would resolve this?

No. A local build with poetry build should already produce correct source- or wheel-names with the version being part of the name. Is that the case?

pkalita-lbl commented 6 months ago

@nicholsn I'm still not quite sure I'm following exactly what's going on here. Maybe if you have time to walk me through it on a developer call sometime?

nicholsn commented 6 months ago

Thanks, @pkalita-lbl - I figured this out and it was an error on my end where my github action was only publishing the source tarball to our internal pypi registry. Fixing the action to publish the whl resolved the issue.