@lubo @nico What do you think about this simple patch?
fc28f58c77
With fc28f58c77080e94215719ba4f2aa3f3162c8300, this finally works:
$ pipenv install -e…
@lubo Well, I have to play with it. It must support different cases. pip from git, git clone + setup, download tar.gz from pypi or gitlab release bundle when it is not a git repo, ...
@lubo This https://code.ungleich.ch/ungleich-public/cdist/blob/build/support-pip-from-git/setup.py should cover git and non git cases.
2d0af7b7ccc34d450a1b0cfb6532f6d2439ee7a4 works when installed from local and remote repository and from generated sdist too.
Although you'll have to reinstall the package if you change something in the editable mode.
@lubo Do you have suggestions for "Although you'll have to reinstall the package if you change something in the editable mode." ?
Maybe you should put version.py to build/lib/cdist, so it's used when building distributable packages, but not locally. Then, if importing version module fails, assume we run in editable mode…
@lubo As I understand, editable mode does some sort of link to source/cloned repo. So if you change something that will reflect package execution. If you change something, then you expect the version…
You'd have to put the same code to cdist/__init__.py too, in addition to setup.py. I think "Package versioning best practices" describes this approach quite well. So, instead of…
I always hated the way cdist version is handled. That's actually the sole reason why I run from a fork which I rebase on top of master with this single commit:
[10:59:54] eos:cdist% git show…
@lubo I agree with @steven. Putting setuptools_scm into cdist is heavy. It seems, currently, that https://code.ungleich.ch/ungleich-public/cdist/tree/build/support-pip-from-git is best effort for…
Okay. So, as I've previously reported, 2d0af7b7ccc34d450a1b0cfb6532f6d2439ee7a4 works for me. Therefore, I'd say ship it and let's leave the issue with version reported by cdist for another time.