On 2012-01-08 21:34, Nick Sabalausky wrote:
"Jacob Carlborg"<d...@me.com> wrote in message
news:jec1j6$2rbu$1...@digitalmars.com...
Ideally it should come before other new features. I mean, the more stuff
we put in there the more mess it will be. The point of the refactoring is
of course to make it easier to add new features and to understand the
code.
Yea, that makes sense. I guess I just wasn't sure how "deep" the refactoring
you were envisioning was going to be.
Quite deep. I want to have it look more like Orbit:
https://github.com/jacob-carlborg/orbit
Instead of having all code in the commands I want to have a single class
for a single task. The commands would then basically just create a new
instance of the needed classes.
Something possibly releated I've been meaning to bring up: I've been
thinking that DVM's commands and options should work more like, say, git or
svn. By that I mean: Right now DVM has a set of commands, and a set of
"global" DVM options. Problem is, some of the options only apply to some of
the commands. This sugegsts a few changes:
1. "dvm --help" should only show globally-applicable options. (--verbose
and --help are probably only ones right now.)
2. "dvm [command] --help" (and maybe "dvm --help [command]", too) should
show a command-specific help screen.
This isn't a *huge* need right now, but I think it'll only become more and
more important as DVM progresses. I don't know if this is something that
should be taken into account in the refactoring, or just left until after.
Yeah, I know. That would be another reason to do the refactoring.
Another thing that might need to be considered in the refactoring: On Linux,
DVM doesn't currently work inside a shell script. It's just not recognized.
I'm sure it probably has something to do with the "dvm" shell-function.
Maybe it's because it's set to only be defined on interactive prompts? I
don't really know for certain what the problem or the solution is, so
depending on whatever the "right" solution is, this might be a "take into
account in the refactoring" matter.
I didn't know about that. I'll take a look at that.
About the refactoring, what to you think about these:
* Move to git
I don't have a really strong opinion on that. While I kind of like Hg a
little better, I normally use the Tortoise tools, and I like TortoiseGit
much better than TortoiseHg. Also branching is built into Git rather than
being a grafted-on extra, which is nice. (And of course, DVM goes
hand-in-hand with DMD and DMD is Git). So I guess I would lean more towards
Git, but either way works.
I've moved all my projects to git, use it at work, so I prefer it over
mercurial.
* Move to github
It's ultimately up to you, but personally I can't stand Github. My vote
would be to stick with Bitbucket.
Granted, I haven't actually tried Bitbucket's Git support yet. But just
yesterday I started the process of converting a couple of my projects from
SVN/Dsource to Git/Bitbucket, so we'll see how it goes, and I'll let you
know.
I'm asking you since you're the main contributor next to me. I prefer
Github, many D project are moving to Github, DMD, Phobos and druntime
are already there. But certainly don't want to push you away, that
wouldn't be good for the Windows port :)
* Port to D2, still using Tango
I'm definitely in favor of switching to D2. In fact, I took the leap from
D1/Tango straight to D2/Phobos on my own projects about a year or so ago, so
I have some experience in that (and D2's only gotten better since), and I'd
be happy to take the lead converting it to D2. I found that the vast
majority of changes I needed to make were Tango->Phobos because, while there
are some breaking changes from D1->D2, most of the changes are additive, and
D1-style code works fine in D2 with only very little change.
As far as Tango: I have no idea what the state of D2's Tango is, and
personally I'd prefer Phobos. But if you have reason to believe D2's Tango
is ready to use and you'd prefer that, then I'm perfectly fine with it.
Actually, heck, if we're going to switch to D2, we may as well at least give
D2's Tango a try along the way. If it works, it works, if it doesn't we can
help out D2's Tango or just do Phobos (especially since 2.058 will have that
new curl module).
I'm pretty sure Tango for D2 is ready enough. I got help porting my
package manager, Orbit, to D2 using Tango. Everything compiles but not
everything works, probably something D2 and Ruby related (TLS or
something like that). But it was surprisingly few changes that needed to
be done and that is all to Tango working with D2. The biggest problem
would be to port the tool to use Phobos instead of Tango.
I guess it would be best to start by adding some high level tests to
DVM. You probably won't like this but there's a great Ruby tool for
testing these kind of things called Cucumber. I'm already using it in
Orbit: https://github.com/jacob-carlborg/orbit/tree/master/features
--
/Jacob Carlborg
