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

[RFC] Introduce attrs #2641

Merged
merged 3 commits into from
Nov 6, 2017

Conversation

RonnyPfannschmidt
Copy link
Member

No description provided.

Copy link
Contributor

@blueyed blueyed left a comment

Choose a reason for hiding this comment

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

👍
attrs is awesome, and would be great to have in pytest.

@The-Compiler
Copy link
Member

Note that attrs doesn't support Python 2.6 (which we said we would support until pip doesn't). I'm also not sure what this means for @hynek's usage of pytest to test attrs.

@RonnyPfannschmidt
Copy link
Member Author

i care about python2.6 a lot less than sorting out cruft, and as far as i can tell the next feature release after 3.2 can drop python2.6 entirely

@RonnyPfannschmidt
Copy link
Member Author

wrt vendoring i just verified with @hynek on irc that vendoring is the better approach in the pytest case in order to ensure sound testing

@nicoddemus
Copy link
Member

i care about python2.6 a lot less than sorting out cruft, and as far as i can tell the next feature release after 3.2 can drop python2.6 entirely

If by pytest-3.3 pip has released 10.0, then I agree completely (including dropping support for python 3.3 as well). Otherwise I would not like to break our promise of only dropping support when pip does.

Copy link
Member

@flub flub left a comment

Choose a reason for hiding this comment

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

My gut instinct is to be -0 on this as a whole. But I'm sure you've all done your homework and it's worth it so I'll change that to +0.

setup.py Outdated
install_requires = [
'py>=1.4.33',
'setuptools',
'attrs',
Copy link
Member

Choose a reason for hiding this comment

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

I might be missing something but didn't attrs just get vendored as well? Why is it also unconditionally part of install_requires?

Copy link
Member Author

Choose a reason for hiding this comment

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

i forgot that while vendoring thanks for the note

@pytest-dev pytest-dev deleted a comment from coveralls Aug 1, 2017
@pytest-dev pytest-dev deleted a comment from coveralls Aug 1, 2017
@jaraco jaraco mentioned this pull request Aug 1, 2017
jaraco
jaraco previously requested changes Aug 1, 2017
Copy link
Contributor

@jaraco jaraco left a comment

Choose a reason for hiding this comment

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

I believe there's a stale comment in the vendored packages README. I suggest it should be updated to include the motivations for vendoring attrs.

@@ -6,3 +6,5 @@
# broken installation, we don't even try
# unknown only works because we do poor mans version compare
__version__ = 'unknown'

from .vendored_packages import attr
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm a little wary of this approach of importing a module simply so it's exposed for other modules to import. It may work for attrs because attrs happens to import all of its submodules, but in the general case, this pattern doesn't work. I considered something like this when vendoring packaging into setuptools, but packaging doesn't import all of its submodules, so an from ._vendor import packaging doesn't expose packaging.specifiers (or simililar), but moreover, it's difficult for another module that needs those submodules to make the submodules available.

This pattern is discouraged for exposing non-vendored functionality, so I think it should be discouraged for vendored as well.

@@ -0,0 +1,71 @@
from __future__ import absolute_import, division, print_function
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm strongly opposed to any vendoring if it can be avoided. I read up on #944, which explains the motivations for vendoring pluggy. Do those same motivations apply for this package? Do those motivations not apply to any package on which pytest depends?

Copy link
Member Author

Choose a reason for hiding this comment

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

@jaraco vendoring atts was suggested as attrs is tested using pytest - and well the only supported way in python to import multiple versions of a package at the same time is to put them under a new name to begin with - even setuptools didnt solve that as multi version install never supported multi version import

setup.py Outdated
'py>=1.4.33',
'six>=1.10.0',
'setuptools',
'attrs',
Copy link
Member

Choose a reason for hiding this comment

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

Probably needs an appropriate version bound.

@RonnyPfannschmidt RonnyPfannschmidt dismissed jaraco’s stale review October 10, 2017 16:40

vendoring was undone, so the complaint was addressed

@pytest-dev pytest-dev deleted a comment from coveralls Oct 10, 2017
@nicoddemus
Copy link
Member

there are ltos of them, but if i do a bug bang convert, all things will break interestingly

OK no worries. It is already a bonus to be able to use attrs for new code. 👍

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0005%) to 92.653% when pulling babe63a on RonnyPfannschmidt:introduce-attrs into 083084f on pytest-dev:features.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0005%) to 92.653% when pulling 2586dec on RonnyPfannschmidt:introduce-attrs into 083084f on pytest-dev:features.

for FixtureFunctionMarker and marks
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0005%) to 92.68% when pulling 07b2b18 on RonnyPfannschmidt:introduce-attrs into cb30848 on pytest-dev:features.

@nicoddemus
Copy link
Member

@RonnyPfannschmidt

wrt vendoring i just verified with @hynek on irc that vendoring is the better approach in the pytest case in order to ensure sound testing

Sorry just noticed now that this comment is ambiguous. Should pytest vendor attrs or the other way around? Just to make sure before we merge this.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.008%) to 92.689% when pulling e58e8fa on RonnyPfannschmidt:introduce-attrs into cb30848 on pytest-dev:features.

@RonnyPfannschmidt
Copy link
Member Author

@nicoddemus we decided not to vendor at all

@hynek
Copy link
Contributor

hynek commented Nov 4, 2017

It would be great if you could add a travis job to test pytest against attrs master to prevent release drama.

@nicoddemus
Copy link
Member

It would be great if you could add a travis job to test pytest against attrs master to prevent release drama.

Great idea.

@nicoddemus
Copy link
Member

nicoddemus commented Nov 4, 2017

Hmm now that I think about it, should we test against the master of each dependency we add? We already do that for pluggy, exactly because we almost made a new pluggy release which by accident would break pytest. The same can be true for any of the new dependencies: attrs, funcsigs or even colorama.

And even testing against master is not 100% safe, consider this situation: someone merges a funcsigs PR (just an example, could be any of the dependencies) and makes a release. Our funcsigs jobs would break with the new master, but in the meantime between the merge and the release no pytest builds have happened (we only build on PRs and merges after all). In this situation it would immediately break pytest.

Of course adding dependencies to a project you add the risk of breaking because of an update on a dependency, it is the trade-off of not having to implement everything yourself.

To be clear: I'm definitely not against adding new libraries, but we should have a clear policy if we will test all dependencies against their development branch or not.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.0005%) to 92.683% when pulling e351976 on RonnyPfannschmidt:introduce-attrs into b18a9de on pytest-dev:features.

@flub
Copy link
Member

flub commented Nov 6, 2017 via email

@RonnyPfannschmidt
Copy link
Member Author

if we go for testing against master of every dependency, then i'd like an new pr preparing that, then hook into it here

@blueyed
Copy link
Contributor

blueyed commented Nov 6, 2017

@nicoddemus

we only build on PRs and merges after all

There are also daily cron builds IIRC?!

@nicoddemus
Copy link
Member

if we go for testing against master of every dependency, then i'd like an new pr preparing that, then hook into it here

OK then sounds good. I will open another PR with that.

@nicoddemus
Copy link
Member

The failure is unrelated, merging this then.

@nicoddemus nicoddemus merged commit c33074c into pytest-dev:features Nov 6, 2017
@RonnyPfannschmidt
Copy link
Member Author

@nicoddemus awesome , thanks
i was preparing myself for it but i keep getting interrupted today

@nicoddemus
Copy link
Member

If you get to it, please go ahead. I'll probably only have time tomorrow anyways. 😇

@RonnyPfannschmidt
Copy link
Member Author

same here ^^, i'll open a issue

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

Successfully merging this pull request may close these issues.

None yet

8 participants