It is our pleasure the announce the first release of ROTOR: a tool for refactoring multi-file OCaml codebases. Currently, it just performs renaming of value bindings, but the intention is for ROTOR to support a full range of refactoring tasks, and to be the go-to refactoring tool for the OCaml community.
ROTOR has been developed at the University of Kent, with the support of Jane Street, as part of a research project on trustworthy refactoring.
It is available now on OPAM:
> opam install rotor
This release is an alpha version, and so we’d love you all to try it out and give us your feedback. Since it is still a prototype, we are certainly not making any claims that it works perfectly in all cases, but we think it is at a stage where it can start to be useful to the community, and where it will be useful for us to seek community feedback.
Please raise any issues on the gitlab page. Please also email us to report on your experiences.
Currently, ROTOR is invoked from the command-line:
> rotor rename [options] <from-id> <to-id>
ROTOR can determine the files that comprise your codebase using .merlin files, and outputs a diff patch which can be applied to effect the renaming. For the future, we are looking at integrating within IDEs, which will make it easier to use.
I requested already at the GitLab, but duplicating here, just in case it was missed. Following the discussions about deprecating Pervasives in OCaml, I think it might be beneficial to define/implement a general way to autodetect and autofix deprecations through dune plugin. A good example how this can be done is Rust’s cargo fix.
I am very excited for this. I’ve been looking at your project for some time now.
I hate to be this guy but did you consider moving to github? I suppose there are certain advantages of gitlab and that’s why you chose it. That said, the social aspects are incredibly important for any OSS project and github, because of the community size alone, wins here.
I use both github and gitlab. Knowing one, it takes virtually no time to make use of the other. I also think there’s inherent value in keeping some small amount of decentralization, so all our eggs aren’t in one basket. (Finally, I prefer git lab, both because of their feature set and commitment to OSS).
@XVilka, no - sorry! We are meeting with Rudi and Jérémie in a couple of weeks to discuss pushing forward on integration with Dune, so hopefully we can get that done before too long.
Yeah, automatic detection and removal of dead code is a much wanted feature.
Personally, I want this when I release part of a research prototype.
Since I want to only export a clean and rather small part of the code
base, I want to remove all dead code.