Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[RFC] Introduce attrs #2641
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.
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.
referenced this pull request
Aug 2, 2017
vendoring was undone, so the complaint was addressed
Sorry just noticed now that this comment is ambiguous. Should pytest vendor
Hmm now that I think about it, should we test against the master of each dependency we add? We already do that for
And even testing against
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.
Yes, testing against master of every dependency seems like a good idea…
On 4 November 2017 at 15:46, Bruno Oliveira ***@***.***> wrote: 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. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#2641 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAI9IOoSd4wvXZUFb-DMZe84WOU4hrpAks5szHjDgaJpZM4OpfXd> .