Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaks pip install -e workflow #4

Open
miohtama opened this issue May 10, 2016 · 5 comments
Open

Breaks pip install -e workflow #4

miohtama opened this issue May 10, 2016 · 5 comments
Assignees

Comments

@miohtama
Copy link

miohtama commented May 10, 2016

If you have installed a dependency using pip install -e setuptools-git-version breaks console entry point startups, because it tries to look absolute version instead of using a development version.

Traceback (most recent call last):
  File "/Users/mikko/code/xxx/venv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 651, in _build_master
    ws.require(__requires__)
  File "/Users/mikko/code/xxx/venv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 952, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/Users/mikko/code/xxx/venv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 844, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (websauna 0.0.27+fee850d (/Users/mikko/code/xxx/websauna), Requirement.parse('websauna==0.0.19+5aed973'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/mikko/code/xxx/venv/bin/ws-alembic", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/Users/mikko/code/xxx/venv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3084, in <module>
    @_call_aside
  File "/Users/mikko/code/xxx/venv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3070, in _call_aside
    f(*args, **kwargs)
  File "/Users/mikko/code/xxx/venv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3097, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/Users/mikko/code/xxx/venv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 653, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/Users/mikko/code/xxx/venv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 666, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/Users/mikko/code/xxx/venv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 839, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'websauna==0.0.19+5aed973' distribution was not found and is required by the application
@miohtama
Copy link
Author

miohtama commented May 24, 2016

How about this: version is always set by default, so pip etc. tools are happy with the package.

version_info is also set, but it does not replace / touch version unless especially specified by environment and setuptools-git-version only replaces version when the package is being packaged and not e.g. during pip install -e. Effectively setuptools-git-version path should be only taken when the package is being prepared for upload, maintaining the legacy compatibility with the fragile corners of setuptools.

/cc @tomster

@miohtama
Copy link
Author

Marrow is another open source project which uses similar git tagging strategy for releases and I am a huge fan of @amcgregor's work there.

They use different strategy to inject git tagging information to version:

https://github.com/marrow/WebCore/blob/develop/setup.py#L25

@amcgregor
Copy link

@miohtama As a minor fun fact, no attempt is made to automatically extract git revision or branch information. The release.py file being included in this way, beyond making static analyzers freak out about all the variables that seem to be missing, requires manual version bumping during bundling. (git flow release start <ver>, bump, git flow release finish <ver>.)

@miohtama
Copy link
Author

@amcgregor Did you have a script somewhere which publishes wheels (eggs?) from tags? I recall seeing it somewhere in Marrow.

@amcgregor
Copy link

@miohtama I actually abuse Tox for this purpose. After a git flow release finish and confirmed Travis test suite run (on both the new master and new version tag), I run through something like: https://github.com/marrow/cinje/blob/develop/tox-dist.ini

Run via: tox -c tox-dist.ini

This bundles up a universal wheel (from 3.4 in this instance), as well as source distribution and "binary" eggs for various runtimes. I'm slowly moving away from this process, though, as my current distribution strategy requires GPG signatures and ./setup.py register sdist bdist_wheel upload -s is sufficient by itself due to the fact my codebases are naturally Python 2 and 3 compatible. (No need for any version-specific eggs any more.)

@witsch witsch self-assigned this May 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants