Refactor Toil to be snake_case while retaining compatibility with Cactus

[y9c]

https://github.com/DataBiosphere/toil/pull/1905#discussion_r140826796

┆Issue is synchronized with this Jira Story ┆Issue Number: TOIL-44

[mr-c]

I would still like to see this happen.

[mr-c]

We need to talk about project governance if you all are going to close issues without discussion.

[adamnovak]

Sorry @mr-c. I forgot that I had closed and you had reopened this before.

Lon and I have been trying to use Jira for more triaging/prioritizing of open issues, but probably you should have access to Jira's (hopefully-eventually-)sorted backlog. Do you want an account on our Jira? I can see if I can get you one. In lieu of scrum-style backlog grooming meetings, since @DailyDreaming and I have so little time available for them, my current plan for project governance is to just have everyone independently rearrange the backlog on Jira wiki-style until it reaches a steady state.

On the actual subject of refactoring Toil to snake case, my initial reaction was that it's not worth doing. I keep thinking that every time I look at this issue, and I keep immediately closing it because of that.

But upon reflection, it's only not worth doing it the hard way. All else being equal, it would be better if this was accomplished. If we could run a tool over the repo to do it, and then make requests from user code for the old names automatically get translated to the new names, then we should do it when there's nothing more important to do, is my new opinion.

We shouldn't do it in a way that requires user workflows to be changed to use the new names. We need to keep compatibility with the existing API, at least until UCSC's big internal customers like Cactus get converted to a new one.

[diekhans]

I don't see how snake-case vs camel-case will make a difference in the success of Toil. The python library isn't even consistent

It hard to justify spending money on it with much higher priority problems.

This is coming from someone who is rather uptight about coding conventions.

Adam Novak notifications@github.com writes:

Sorry @mr-c. I forgot that I had closed and you had reopened this before.

Lon and I have been trying to use Jira for more triaging/prioritizing of open issues, but probably you should have access to Jira's (hopefully-eventually-)sorted backlog. Do you want an account on our Jira? I can see if I can get you one. In lieu of scrum-style backlog grooming meetings, since @DailyDreaming and I have so little time available for them, my current plan for project governance is to just have everyone independently rearrange the backlog on Jira wiki-style until it reaches a steady state.

On the actual subject of refactoring Toil to snake case, my initial reaction was that it's not worth doing. I keep thinking that every time I look at this issue, and I keep immediately closing it because of that.

But upon reflection, it's only not worth doing it the hard way. All else being equal, it would be better if this was accomplished. If we could run a tool over the repo to do it, and then make requests from user code for the old names automatically get translated to the new names, then we should do it when there's nothing more important to do, is my new opinion.

We shouldn't do it in a way that requires user workflows to be changed to use the new names. We need to keep compatibility with the existing API, at least until UCSC's big internal customers like Cactus get converted to a new one.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/DataBiosphere/toil/issues/2567#issuecomment-493524657 Sorry @mr-c. I forgot that I had closed and you had reopened this before.

Lon and I have been trying to use Jira for more triaging/prioritizing of open issues, but probably you should have access to Jira's (hopefully-eventually-) sorted backlog. Do you want an account on our Jira? I can see if I can get you one. In lieu of scrum-style backlog grooming meetings, since @DailyDreaming and I have so little time available for them, my current plan for project governance is to just have everyone independently rearrange the backlog on Jira wiki-style until it reaches a steady state.

On the actual subject of refactoring Toil to snake case, my initial reaction was that it's not worth doing. I keep thinking that every time I look at this issue, and I keep immediately closing it because of that.

But upon reflection, it's only not worth doing it the hard way. All else being equal, it would be better if this was accomplished. If we could run a tool over the repo to do it, and then make requests from user code for the old names automatically get translated to the new names, then we should do it when there's nothing more important to do, is my new opinion.

We shouldn't do it in a way that requires user workflows to be changed to use the new names. We need to keep compatibility with the existing API, at least until UCSC's big internal customers like Cactus get converted to a new one.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[diekhans]

btw, my comment isn't to suggest this be closed, only that it be made low-priority.

[DailyDreaming]

Wouldn't mind seeing this either, but fairly low priority for us. Will likely just see it slowly added to the codebase over time.

[adamnovak]

It would be nice if we could make PyCharm or something do this. We'd probably want to compile a list of all Toil symbols accessed by Cactus and toil-vg (and other Python workflows that might be representative) and leave in some deprecated accessors under the old names. I'm not sure PyCharm is clever enough to also so that.

[unito-bot]

➤ Adam Novak commented:

We should probably give up on general workflow compatibility and just make corresponding changes to Cactus. We might need to make sure Cactus is using maximum versions in any Toil dependencies properly first.