Re: [pytest-dev] [proposal] introducing attrs to the codebase

Hi Ronny, Could you list the classes which you think would be changed to use 'attrs'? I'm not against adding another dependency if it can help us maintain the codebase. Also, introducing a new dependency should be done in `3.1.0`, not in a patch release. Cheers, Bruno. On Tue, Dec 6, 2016 at 5:4

Re: [pytest-dev] [proposal] introducing attrs to the codebase

Hey there, I don’t mind adding a dependency as long as there is a need for it. +1 The problem I see with ‘attrs’ as it stands today, is that it does not support Python 2.6 whereas pytest does. So we probably want to get https://github.com/pytest-dev/pytest/issues/1273

Re: [pytest-dev] [proposal] introducing attrs to the codebase

Oh good point Raphael. Here's the link for the discussion about pip dropping Python 2.6: https://github.com/pypa/pip/issues/3955 Cheers, Bruno On Tue, Dec 6, 2016 at 8:57 AM Raphael Pierzina wrote: > Hey there, > > I don’t mind adding a dependency as long as there is a need for it. +1 > > The

Re: [pytest-dev] [proposal] introducing attrs to the codebase

*resend after mistake* Hi Bruno, i was thinking of doing it in the features branch, as far as i can tell it can be applied to all classes of the code/traceback, report and node details as well of a lot of mark related inner details having low cost classes should also ease de-tangling node mark h

Re: [pytest-dev] [proposal] introducing attrs to the codebase

On Tue, Dec 6, 2016 at 9:52 AM Floris Bruynooghe wrote: > > As an aside, if we're happy to introduce more libraries then maybe we > should also consider the standard six package instead of doing our own > stuff, mostly because I'd make it easier for new contributors. > I had this in mind as well

Re: [pytest-dev] [proposal] introducing attrs to the codebase

Hi, Personally I also don't mind the dependency. Though I know in the past we've had a policy of keeping dependencies to a minimum as well as licenses. Attrs uses MIT as well so that should not be a problem. One thing which does stand out is that attrs is at v16, suggesting they break their API a

Re: [pytest-dev] [proposal] introducing attrs to the codebase

Hi, attrs is version 16 since it uses CalVer, not SemVer. Also see: https://attrs.readthedocs.io/en/stable/backward-compatibility.html > Date: Tue, 6 Dec 2016 11:52:05 + > From: Floris Bruynooghe > To: Bruno Oliveira > Cc: [email protected], Raphael Pierzina > Subject: Re: [pytest-de

Re: [pytest-dev] [proposal] introducing attrs to the codebase

Hi! The v16 is because it uses time based version numbering. Regards, Florian Schulze On 6 Dec 2016, at 12:52, Floris Bruynooghe wrote: Hi, Personally I also don't mind the dependency. Though I know in the past we've had a policy of keeping dependencies to a minimum as well as licenses. Att

Re: [pytest-dev] [proposal] introducing attrs to the codebase

Attrs dropped 2.6 pretty recently, it might be reasonably easy to add/keep the support for the pip timeframe as well on the upstream, i'll check wit the author 2016-12-06 12:15 GMT+01:00 Bruno Oliveira : > Oh good point Raphael. > > Here's the link for the discussion about pip dropping Python 2.