remove deprecated skip_equivalent from pyproj #43
Conversation
mesa_geo/geospace.py
Outdated
| @@ -96,7 +94,7 @@ def get_intersecting_agents(self, agent, other_agents=None): | |||
| return intersecting_agents | |||
|
|
|||
| def get_neighbors_within_distance( | |||
| self, agent, distance, center=False, relation="intersects" | |||
| self, agent, distance, center=False, relation="intersects" | |||
There was a problem hiding this comment.
This is an unnecessary indentation.
There was a problem hiding this comment.
Thank you for spotting this! It's probably due to the auto formating tool from my IDE.
|
Merged as 75d356e. |
|
Hmmm, while it is common for some FOSS projects to merge it the way I just did, 75d356e doesn't link to this PR. This way, generating the changelog items will be harder, where we usually link to the relevant PRs. I'm not going to do this in the future. |
This is interesting to know - all my previous projects (proprietary software) were using the merge method with In the future for If yes then perhaps we can also standardise and mention it in the CONTRIBUTING.rst. |
|
Squashing all commits is problematic, see e.g. JuliaDynamics/Agents.jl@b1cd6a8, which is a giant commit where the intent of each individual change is hard to read. I favor atomic commits that each logically do different things. Which means, small changes with nonsensical commit message should be squashed into the closest commit that does the same thing. It is a bit too much to expect every contributor to do this fine-grained squashing, but then again, it is super rare for a contributor to create a large PR in the first place. |
|
Though you could argue that in JuliaDynamics/Agents.jl@b1cd6a8, you can still see individual commits in the pull requests. |
|
Yeah I agree that squashing is problematic, guess this is why I seldom use it over the years. On the other hand, if individual commits are preserved and the rebase method is used for pull requests, then the history of the main branch will be full of these small commits from different branches intertwined. This is basically why we (my previous projects) preferred the merge method with |
|
I just remembered one reason keeping the commits separate instead of squashed for each PR is worthwhile: doing git-bisect to find a commit that causes a bug is much easier, vs narrowing it down to 1 giant commit. |
|
Yup! |
Fix #39 due to pyproj4/pyproj#824