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

[WIP] oslo-config: 4.13.2 -> 5.1.0 #32602

Closed
wants to merge 39 commits into from

Conversation

makefu
Copy link
Contributor

@makefu makefu commented Dec 12, 2017

Motivation for this change

bump oslo-config to 5.1.0 and enable tests 💯

For enabling tests i had to bump:

  • reno: 2.3.2 -> 2.6.0
  • bandit: 0.16.0 -> 1.4.0
  • openstackdocstheme: init at 1.17.0
  • pyasn1-modules: 0.1.5 -> 0.2.1
  • ldappool: 1.0 -> 2.1.0
  • pythonPackages.ldap: 2.4.45 -> 3.0.0b2

Waiting for @GrahamcOfBorg :3

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • [NA] Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@makefu makefu requested a review from FRidh as a code owner December 12, 2017 15:17
Copy link
Member

@FRidh FRidh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

propagatedBuildInputs = [ pbr six pyyaml appdirs stevedore GitPython git ];
checkInputs = [ beautifulsoup4 oslosphinx testtools testscenarios
testrepository fixtures mock ];
patchPhase = ''
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

postPatch is preferred so that one can still pass in patches.

@FRidh
Copy link
Member

FRidh commented Dec 12, 2017

oslo-config bump is likely to break things though. That needs to be checked first.

@makefu
Copy link
Contributor Author

makefu commented Dec 12, 2017

i am currently on it, i will have to bump a number of libs to get it running. changing Headline to WIP

@makefu makefu changed the title oslo-config: 4.13.2 -> 5.1.0 [WIP] oslo-config: 4.13.2 -> 5.1.0 Dec 12, 2017
@makefu
Copy link
Contributor Author

makefu commented Dec 12, 2017

oh oh, it seems that bumping pyasn1 was not the wisest thing to do. it was for getting ldap to the latest version ... i will see how much stuff breaks with this.

@makefu
Copy link
Contributor Author

makefu commented Dec 12, 2017

can this PR be submitted to hydra for evaluation? i am afraid my pc is not hardcore enough to evaludate the PR in time. if it is not possible then i will probably have to revert and wait for pyasn1 be bumped by someone more adventurous than me.

edit ok i will give up trying to bump ldap and pyasn1. i will keep put this in a separate PR

@makefu
Copy link
Contributor Author

makefu commented Dec 12, 2017

for python3Packages.oslo-config i get

error: invalid command 'bdist_wheel'

however the package is building for python2. @FRidh you had similar issues before? i tried to put wheel in every *Inputs list without success.

@FRidh
Copy link
Member

FRidh commented Dec 12, 2017

That typically happens when Python 2 and 3 packages get mixed during a build. Both packages have the interpreter in propagatedBuildInputs, and the interpreters each a setup hook that extend to the same PYTHONPATH. That causes trouble. In this case, certain Python 2 applications are added in the build when tests are enabled. I suggest for now disabling tests for Python 3 builds.

@FRidh
Copy link
Member

FRidh commented Dec 12, 2017

When disabling tests, can you refer to the previous comment.

@makefu
Copy link
Contributor Author

makefu commented Dec 12, 2017

@FRidh i think the package is reno (which comes from top-level/all-packages.nix), the correct way would be to pull reno into pythonPackages again, right?

update: yep it is the reno package

@FRidh
Copy link
Member

FRidh commented Dec 12, 2017

@makefu if its just an application, and we're not interested in the modules, then no, then its not the correct way to pull it into python-packages.nix. But it is a pragmatic way to get your tests working ;-)

The correct way, but out of scope here, is to make sure Python applications don't show their site-packages to the hook.

@makefu
Copy link
Contributor Author

makefu commented Dec 13, 2017

so many broken packages ... is it possible with nox-review pr to check for all packages which broke due to the pr?
a lot of issues due to argparse, not sure why this happens though. i would really fix the packages but moving them one-by-one to development/python-modules is quite some effort to go through

@FRidh
Copy link
Member

FRidh commented Dec 13, 2017

so many broken packages ... is it possible with nox-review pr to check for all packages which broke due to the pr?

nox-review computes what needs to be rebuild and then builds it. You could use niff to just check what packages need to be rebuild. Its in Nixpkgs.
https://github.com/FRidh/niff

a lot of issues due to argparse, not sure why this happens though.

A lot of (older) packages have an install_requires on argparse, even though argparse is part of stdlib in 2.7+. We typically patch that dependency out.

i would really fix the packages but moving them one-by-one to development/python-modules is quite some effort to go through

Absolutely. Many of the packages you touch haven't been used in a while. It may therefore also be wise to evaluate whether they could instead be dropped.

I would prefer to move this whole openstack stuff out into an overlay. Its a pain to maintain, and its presence puts a burden on others that are contributing as well.

@makefu
Copy link
Contributor Author

makefu commented Dec 13, 2017

Moving openstack out may be a good idea, this looks like a never ending rabbit hole of (circular) dependencies.

What i could think of is using pypi2nix and just freeze all required applications (with tests disabled) and refreeze on each version change.

Edit: i just remembered why i started this in first place, which is sqlalchemy_migrate which depends on some of this clusterfuck (tempest-lib that is)

@FRidh
Copy link
Member

FRidh commented Dec 13, 2017

What i could think of is using pypi2nix and just freeze all required applications (with tests disabled) and refreeze on each version change.

Won't help, because we need a coherent set that works for Python 2.7, 3.4, 3.5, 3.6 and preferably also PyPI. With pypi2nix you generate for one version.

But I thought that certain openstack libraries were already marked as broken, so I wouldn't imagine you having to upgrade them then.

@makefu
Copy link
Contributor Author

makefu commented Dec 13, 2017

Thing is, that the update resulted in more dependencies which resulted in new errors (and more update) and more dependencies. a never ending cycle.

Regarding the overlay, i think only a single python version would be enough to provide the functionality of openstack. This however would not solve the issue if people would actually want to use certain libraries in their project.

imho each module should come with a huge warning sign if it pulls dependencies from openstack ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants