IMPORTANT: dedalus2 --> dedalus

[j s oishi]

Hi all,

Keaton, Ben, and I have all discussed the idea of changing the base name of the package (and thus the repository) from dedalus2 to dedalus. I think this is much cleaner and a change we need to make as soon as possible, since more people are starting to come to the community. 

However, this will have a number of important effects. First, the repository will move, necessitating updates to all your outstanding .hgrc files, and those of your dev forks. I just performed a test: if you don't care what the *name* of your dev fork is, changing the name of the repository it is forked from won't make a difference. Second, all existing scripts will need to be corrected to read

import dedalus.public as de

instead of the current

import dedalus2.public as de

for example. 

I'd like to do this *after* we decide what to do about the two outstanding pull requests. However, I'd also like to ensure we do this by the end of this week (Friday 6 June). 

I'd like to hear from everyone about their thoughts on this change and the timetable for doing so. If you have any concerns or questions, please let us know. 

thanks,

Jeff

[Ben Brown]

All,

   I concur on this change. Sooner is better. Today isn't too early (but Friday is fine). 

--B

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "Dedalus Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dedalus-dev...@googlegroups.com.
To post to this group, send email to dedal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dedalus-dev/CAAOZTN8MV9vg1-vVWO8shPu0M-1jvCOjp13tA_oyp%3D7%3DHUr4%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Brown]

All,

     Can we proceed with this change?  I'd like us to do the "dedalus2"->"dedalus" change over before new users (e.g., Brad Marston, Ellen Zweibel) start using the tool, and they nominally are building their software stacks now.

--Ben

--

[Keaton Burns]

I guess I keep waffling on this... it's certainly would be ugly to refer to the code as "Dedalus2", so I think (just as we've been doing) it completely makes sense to just call it "Dedalus" on the webpage, in talks, etc, etc.

However, in terms of the actual package name, I think having the "2" doesn't have substantial drawbacks (you can symlink it into your python path and/or import it under any name you like), is really necessary in order to run both the new version and the old version (which is still publicly hosted under the name dedalus) on the same machine (which goes hand-in-hand with the fact that it really is a distinct code from the first version).

To view this discussion on the web visit https://groups.google.com/d/msgid/dedalus-dev/CAHqBLzxgsUHHw5aVzGyaWZ4Trx0kyw1_Pefm2Tm_D%3D3DkwDZUA%40mail.gmail.com.

[Ben Brown]

All,

     I really don't like having "dedalus2" especially when we're publically calling the code/framework "Dedalus". 

I agree that there should be a distinction between version 1 and our current version, but since version 1 doesn't exist in the broader publication sphere, I'd suggest we call it something like "Dedalus-triple" or something that adequately describes the differences, rather than "dedalus1" and "dedalus2".  I think the "1", "2" numbering convention will just confuse adoptees.  This might be different if there was a broad established user base using version 1.

I'm open to being convinced that "dedalus2" is worth the confusion, but my preference would be to go to "dedalus" for the main repo/package name.

--Ben

To view this discussion on the web visit https://groups.google.com/d/msgid/dedalus-dev/B66A39E0-D30B-4CAA-8714-72415971E036%40gmail.com.

[Keaton Burns]

I just think that the actual package name used on import is largely inconsequential to the experience of using the code, but changing it now is sort of a pain… since it conflicts with an existing package, and also breaks bitbucket's tracking of all previous changes to the core modules.

Also while we don’t have a methods paper out for it, there have been talks and proposals written referencing the first version of the code as just “dedalus”, so renaming it a-posteriori also isn’t ideal.

I’m also open to being convinced but I’m just trying to point out that there are real problems to consider with changing it now.

[Keaton Burns]

Also I think the trailing-integer naming scheme for major changes like this isn’t unprecedented (e.g. Gadget).

[Ben Brown]

On Thu, Jun 12, 2014 at 2:20 PM, Keaton Burns <keaton...@gmail.com> wrote:

I just think that the actual package name used on import is largely inconsequential to the experience of using the code, but changing it now is sort of a pain… since it conflicts with an existing package, and also breaks bitbucket's tracking of all previous changes to the core modules.

I'm a bit confused on this: the history should transfer just fine.  And when we move the bitbucket repo itself, we can have dedalus2 forward reference to dedalus (I've done this with previous deleted repos).  Am I missing a deeper conflict?

I think the package name is non-trivial.  I think that's how most people will come to refer/think about the framework, and I think the 2 distinction adds confusion without significant gain.  Gadget and other codes have done this, but only after years of broad use.  We don't have that historic community lockin.

[Keaton Burns]

I'm a bit confused on this: the history should transfer just fine.  And when we move the bitbucket repo itself, we can have dedalus2 forward reference to dedalus (I've done this with previous deleted repos).  Am I missing a deeper conflict?

Take a look at the link I posted on the issue.  The commit log doesn’t disappear, but you lose the ability to trace development within modules (which is what makes diff-based version control useful when a complicated regression occurs) because bitbucket sees the renaming purely as deleting one file (with history) and adding a brand new one.

I think the package name is non-trivial.  I think that's how most people will come to refer/think about the framework, and I think the 2 distinction adds confusion without significant gain.  Gadget and other codes have done this, but only after years of broad use.  We don't have that historic community locking.

Hmm I don’t know, I just don’t think anyone will have a hard time understanding the idea that they’re using the second version of a code.