[CLOSED] Should we move all Marvin ModelClasses into Marvin? about marvin HOT 5 CLOSED

Comment by havok2063
Thursday Jul 07, 2016 at 14:43 GMT

I'm fine with this as long as we leave the current versions of them in sdss_python_module for all the other code. At least until the point where I can migrate that code over to use Marvin instead.

Marvin still makes a new DatabaseConnection using sdss_python_module, so the dependency is not completely gone. We would need to refactor that a bit. Unless we bring all of that code over into Marvin then we will still have a dependency. Either on sdss_python_module or whatever product contains SDSSDbConnect (Totoro or some new thing).

from marvin.

Comment by albireox
Thursday Jul 07, 2016 at 19:32 GMT

I think there are two options here:

• Copy the SDSSDbConnect code here, and refactor it (always refactor) to serve our purposes.
• Add SDSSDbConnect as a submodule of Marvin (see here for submodules) so that we can use it as part of Marvin.

I like to keep things modular, but at some point it may just be simpler to consolidate everything in Marvin and be done with it.

from marvin.

Comment by havok2063
Thursday Jul 07, 2016 at 20:09 GMT

This sounds like something to be discussed and done during the Seattle MarvinWeek. We can probably rapidly refactor this when sitting next to each other. Presumably Totoro would then use the same submodule?

from marvin.

Comment by albireox
Thursday Jul 07, 2016 at 20:12 GMT

Yes, let's discuss this in Seattle. It should be easy to do once we get to an agreement.

Originally I used SDSSConnect as a submodule in Totoro, but it was a nightmare to keep things working with the SVN. That's something we should consider if we go with the submodule option.

from marvin.

Comment by albireox
Thursday Oct 06, 2016 at 19:19 GMT

This has already been done and is working. Marvin does not depend on sdss_python_module anymore (and the crowd goes wild).

from marvin.