ekr-study-rope: a throw-away repo

[edreamleo]

ekr-study-rope let's me:

• back up experimental work online.
• fix controversial code hangnails.
• freely experiment without fear of accidentally polluting Rope's official code.

As soon as I created this repo my concerns about code squabbles vanished :-)

Hehe. I immediately realized that I had no idea what Rope's code does or how it does it! (This is a statement of my ignorance, not a comment on Rope's code quality.) I'll discuss the way forward in another discussion.

Summary

I'm happy to be a subordinate Rope dev, but I must control my own experiments.

These experiments will be both public (because they're in a public repo) and private (because they will never affect Rope directly).

[lieryan]

When it comes to ropes code quality, I think it's generally pretty good, it's just they very often follow very old practices and some of the string processing that it does can look a bit like C-style thinking translated into Python syntax. But they're nonetheless still quite well written and structured.

Rope's codebase predates the existence of many of the modern tools and standard library improvements that we often nowadays take for granted, and so there are a lot of things it does that are just well written, but old school.

For example, there are many parts of the code that probably should've been using list comprehension, generators, context manager, or pathlib. Back then those aren't features that are available nor you can take for granted will be available on the version of Python on the user's machine.

The oldest commit in rope repository dates back to 2006. At that time the state of the art was Python 2.5, Git was only in the early days, GitHub didn't even exist yet.

It's actually quite a wonder that back when I picked the project up a couple years ago, most of Rope still worked fairly well despite nearly a decade of very little development activities.

[lieryan]

ekr-study-rope

No issue with that, it's your fork so you can do whatever you want or need. Though I'm just wondering why you created a new git repo for that, instead of just using the actual GitHub fork feature.

If you used a fork, GitHub would've linked your repo with the main repo, and provide some useful features around that. A fork is still a fully independent GitHub repository, so it still has basically all the Git and Github features.

The git history is probably one of the best tool to study code, I used git blame quite a lot to dig through the history. But with the history's gone by resetting the history of the code, that wouldn't be easily possible to do that. If you want to remove all the distracting files you don't need while still keeping the history, what you can do is to just clone the main repo, delete all the files in that repo except the .git folder and paste your cleaned up version on to the folder. Git would detect you have deleted a bunch of file, so just make a commit and you'll be back in action with the same set of files you currently have, but with history.

[lieryan]

Another thing to be aware about, removing the authorship information (as recorded in git history) and license file, and then putting it out publicly accessible is technically violating the terms for LGPL.

Personally, I don't see too much issue with it. Considering what you're intending to use this repo for, it's not intended to be a distribution. But putting it somewhere publicly accessible necessarily implies that it could be a distribution, whether intended or not, so the license terms would applies.

However, whether see it as an issue isn't very important, as I'm not the copyright owner of the entire codebase, each author of a patch to the project retains copyright ownership of their contribution (even if they just fixed a single typo somewhere and never come back to rope), so I can't really speak for all the other people who've contributed code to rope. So, while I don't really see it as a problem, other people that's a stickler for open source licensing might take issue with it.

[edreamleo]

@lieryan Many thanks for your comments. You've convinced me to try using ekr-fork-rope2 again.

The problems I have had with ekr-fork-rope2:

• There seems to be no perfect way to ignore rope.leo.
  Adding *.leo to .gitignore created synchronization problems between branches.
• I wanted to use PR 587 for all my experiments. But there is a better way. See below.

My new plan

• Create a new branch (in ekr-fork-rope2), say ekr-study.
  ekr-study will be based on master, augmented with PR 587.
• Backup my work using a new PR, based on ekr-study.
  This PR will forever remain a draft, and will say so in its first comment.
• Attempt to better understand and resolve the issues with rope.leo.
• Add the license and readme files to ekr-study-rope.
  I'll delete ekr-study-rope if the new workflow proves satisfactory.

[lieryan]

How about adding to .git/info/exclude? That's basically .gitignore, except it's not checked in into the repository, so it's just in your local system. You can use a Dropbox like file syncing service if you need it to be available in multiple machines.

[lieryan]

It's up to you how you want to set up your env, but here is how I would have done this:

You create your personal modifications in one branch, say ekr-master branch, which is basically rope's mainline master plus your personal modifications, that branch should be the default branch of your ekr-rope GitHub fork.

Whenever you're working on rope, with every new feature, you create another branch for that feature from mainline's master, say feature-xyz-with-ekr-master, and then merge ekr-master into it. Then when you're done and you want to make a PR, you'd just need to create a new branch feature-xyz and then rebase/cherry pick commits from feature-xyz-with-ekr-master branch to remove the ekr-master commits.

During PR, a couple things might happen:

1. The PR could take a long time and lots of back and forth. During this time, you may have already started working on another branch which gets merged to master first. So you just need to go to ekr-master and pull mainline rope's master, and then go to feature-xyz-with-master and pull ekr-master.
2. I or another contributor might make changes directly to your feature-xyz branch to suggest changes. When the happens, you just go to feature-xyz-with-master and pull that changes from feature-xyz.

When the PR is merged, you merge feature-xyz into feature-xyz-with-ekr-master, then merge feature-xyz-with-ekr-master to ekr-master.

From time to time, you'd merge main rope's master to ekr-master to grab the latest changes from other contributors.

If you want to use Github features like PR viewer, you can make PR from your feature-xyz-with-ekr-master to ekr-master.

All this sounds complicated, I can probably make a graph of it to make it easier to digest, but essentially it just boils down to: ekr branches <- feature branch -> mainline branches and ekr branches <- mainline branch are allowed. But never ekr branches -> mainline branch.

Or in other words, commits only flow from mainline rope to ekr-master, but to go the other way around, you need to rebase/cherry pick into a cleaned up branch.

[edreamleo]

@lieryan Great idea. Thanks.

[edreamleo]

@lieryan Your workflow makes sense, if I understand it correctly. My plans:

I am about to delete the duplicate ekr-study-rope repo.

I'll do all further work in ekr-rope-fork2.

The ekr-devel branch will be the base of all my experiments. I have merged PR #580 and PR #602 into ekr-devel. Merging these PRs allows me to ignore the present controversies.

PR #600 records diffs between master and ekr-devel. I won't update PR #600 unless I do something significant.

[edreamleo]

@lieryan I've thrown away this throw-away repo :-) Thanks for your guidance.