Skip to content

Try unpinning testing reqs #2863

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

Closed
wants to merge 4 commits into from
Closed

Try unpinning testing reqs #2863

wants to merge 4 commits into from

Conversation

agjohnson
Copy link
Contributor

No description provided.

@agjohnson agjohnson added the PR: work in progress Pull request is not ready for full review label May 22, 2017
@agjohnson agjohnson modified the milestone: Cleanup May 22, 2017
@agjohnson agjohnson requested a review from ericholscher May 24, 2017 21:08
@@ -305,7 +305,7 @@ def save(self, *args, **kwargs):
if token is None:
token = default_token()
self.provider_data = {'token': token}
super(GenericAPIWebhook, self).save(*args, **kwargs)
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason we're removing *args? If someone passes in args, we don't want it to explode?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this should always be kwargs, but yeah, probably safest as *args, **kwargs

prospector
pylint-django<0.7
pyflakes<1.2.0
Copy link
Member

Choose a reason for hiding this comment

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

Believe we've run into issues with these upgrading and breaking stuff, is there a strong case for unpinning?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I haven't run into any issues other than more linting errors. We were only pinned because we hit a bug with the latest version at some point. We should be pinned to something more recent.

@agjohnson
Copy link
Contributor Author

This looks to raise even more linting problems, we can address this after #2819 and all the other linting PRs are merged.

@agjohnson agjohnson added the Status: blocked Issue is blocked on another issue label May 24, 2017
agjohnson added 4 commits June 9, 2017 09:51
This addresses no-else-return, which removes a `return` in an `else` after an
`if` that already has a `return`. This makes the default return more obvious in
most cases.
@agjohnson
Copy link
Contributor Author

agjohnson commented Jun 13, 2017

I've updated this with the new rules that a modern pylint brought in, namely:

  • child class method arguments differ from super class arguments
  • a few cases of variables being redefined
  • using if len(array) > 0 -> if array

I also broke out, in a separate commit 0ab73a3, removing unnecessary else statements after a conditional with a return. It might be easier to review as it's own commit.

For the differing arguments, i followed the guideline of:

  • Match the arguments if we were being lazy and didn't replicate the arguments
  • If there are a number of arguments and it doesn't make sense to replicate the call signature, mark as pylint disabled.
  • Mark as disabled if there is an actual case for it

@@ -48,7 +48,7 @@ def force(self, **__):
log.info("Forcing a build")
self._force = True

def build(self, id=None, **__): # pylint: disable=redefined-builtin
def build(self):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

As far as i could tell, there were no child classes using any arguments on this method, and no calls with arguments. It seems safe to remove this, unless there is something hidden using these.

Copy link
Member

@ericholscher ericholscher 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, just a few small nits/questions

- settings
- tastyapi
- templates
- vcs_support
Copy link
Member

Choose a reason for hiding this comment

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

Rinse and repeat :)

json.dumps({'removed': True}),
status=200,
content_type="application/json"
)
Copy link
Member

Choose a reason for hiding this comment

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

Should we just delete this file?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Perhaps with another PR? I don't think the bookmarks code needs to live in our repo

def save(self, *args, **kwargs):
obj = super(VersionForm, self).save(*args, **kwargs)
def save(self, commit=True):
obj = super(VersionForm, self).save(commit=commit)
if obj.active and not obj.built and not obj.uploaded:
trigger_build(project=obj.project, version=obj)
return obj
Copy link
Member

Choose a reason for hiding this comment

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

I do worry that this class of change will have spiraling effects that only show up in run time. Is there a reason we don't want to continue accepting args & kwargs for these things?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In this case, we should have never pushed *args, **kwargs, as it was just lazy. commit=True is more explicit and is now identical to the underlying method signature.

In cases where there are many arguments, I don't know what's best there. *args, **kwargs is flexible for future compatibility, so probably in that case it's fine to ignore the linting error and use the *args, **kwargs catch all.

@@ -36,7 +36,7 @@ def prune_major(self, num_latest):
all_keys = sorted(set(self._state.keys()))
major_keep = []
for __ in range(num_latest):
if len(all_keys) > 0:
if all_keys:
Copy link
Member

Choose a reason for hiding this comment

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

Seems like the previous approach was more explicit (eg. it must be a list, and will raise an exception if None is there). Not sure if we care, but it does seem like this is changing logic some.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For this particular case, all_keys will always be a sequence, so this logic hasn't changed.

If there is a case where the sequence being tested could be None, we should test for that instead of relying on an exception being thrown from len(). if len(sequence) is also described as an anti-pattern in pep8, so I tend to agree with this sort of change.

@agjohnson agjohnson added PR: ready for review and removed PR: work in progress Pull request is not ready for full review Status: blocked Issue is blocked on another issue labels Jun 14, 2017
@ericholscher
Copy link
Member

@agjohnson believe this can be closed?

@agjohnson
Copy link
Contributor Author

Yup, it should be all merged. In fact, not really sure why the merge to master didn't close this PR automatically.

@agjohnson agjohnson closed this Jun 15, 2017
@stsewd stsewd deleted the tox-depends branch September 6, 2018 20:21
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.

2 participants