Skip to content

Improve Makefile to clean __pycache__ directory recursively#611

Merged
seisman merged 1 commit intomasterfrom
clean-pycache
Sep 17, 2020
Merged

Improve Makefile to clean __pycache__ directory recursively#611
seisman merged 1 commit intomasterfrom
clean-pycache

Conversation

@seisman
Copy link
Member

@seisman seisman commented Sep 17, 2020 •
edited
Loading

Description of proposed changes

Running make clean only deletes the pycache directory in the
project root. There are still a few pycache directory left in the
subdirectories.

Reminders

  • Run make format and make check to make sure the code follows the style guide.
  • Add tests for new features or tests that would have caught the bug that you're fixing.
  • Add new public functions/methods/classes to doc/api/index.rst.
  • Write detailed docstrings for all functions/methods.
  • If adding new functionality, add an example to docstrings or tutorials.

@seisman seisman added the maintenance Boring but important stuff for the core devs label Sep 17, 2020
@seisman seisman added this to the 0.2.x milestone Sep 17, 2020
@seisman seisman requested a review from weiji14 September 17, 2020 19:38
@seisman
Copy link
Member Author

seisman commented Sep 17, 2020

@weiji14 Just a quick off-topic question: should we use milestone 0.2.1 instead of 0.2.x? I think 0.2.1 is easier for us and others to track the changes in a single release. If we decide to release 0.3.0 instead of 0.2.1, it's also much easier to changes all 0.2.1-related PRs/issues to 0.3.0.

weiji14
weiji14 approved these changes Sep 17, 2020
View reviewed changes
Copy link
Member

@weiji14 weiji14 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, didn't realize there were so many nested pycache directories!

One thing that bugs me is that the Makefile commands are very UNIX specific (i.e. it works on Linux/macOS, but not on Windows). But that's for a separate PR.

@weiji14 Just a quick off-topic question: should we use milestone 0.2.1 instead of 0.2.x? I think 0.2.1 is easier for us and others to track the changes in a single release. If we decide to release 0.3.0 instead of 0.2.1, it's also much easier to changes all 0.2.1-related PRs/issues to 0.3.0.

No strong preference, happy to go with it (though I do like that milestone v0.2.x is at https://github.com/GenericMappingTools/pygmt/milestone/2 and milestone v0.3.x is at https://github.com/GenericMappingTools/pygmt/milestone/3, but that is bound to break at some point).

@seisman
Copy link
Member Author

seisman commented Sep 17, 2020

One thing that bugs me is that the Makefile commands are very UNIX specific (i.e. it works on Linux/macOS, but not on Windows). But that's for a separate PR.

I believe we will fix it when a Windows developer joins the team.

No strong preference, happy to go with it (though I do like that milestone v0.2.x is at https://github.com/GenericMappingTools/pygmt/milestone/2 and milestone v0.3.x is at https://github.com/GenericMappingTools/pygmt/milestone/3, but that is bound to break at some point).

OK. I'll change the milestones later.

@seisman seisman modified the milestones: 0.2.0, 0.2.1 Sep 17, 2020
@seisman seisman merged commit f0bd178 into master Sep 17, 2020
@seisman seisman deleted the clean-pycache branch September 17, 2020 21:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@weiji14 weiji14 weiji14 approved these changes

Assignees

No one assigned

Labels

maintenance Boring but important stuff for the core devs

Projects

None yet

Milestone

0.2.1

Development

Successfully merging this pull request may close these issues.

2 participants

@seisman @weiji14