Finish updating core nodes for V2 on conda-forge

[borupdaniel]

As far as I can tell, here's what I need to take care of tomorrow to make things look the way we'd like prior to submitting the core nodes recipe to conda-forge for approval:

• [x] Core nodes library: update all "core" imports to "gpi_core"
• [x] Remove .gpi_node_lib_config (switching to name recognition)
• [x] Update the core nodes feedstock to have the appropriate name
• [x] Build the core-nodes without testing
• [x] Framework: change default libraries to search for anything called gpi_
• [x] Make a new build of the updated framework
• [x] Install and test to see if things work / how the nodes appear
• [x] Update framework to strip the "gpi_" at the start of condo-forge packaged node libs
• [x] Another framework build
• [x] Test and build test network, upload network to core-nodes
• [x] Final core-nodes build with testing added back
• [x] Create final release candidate tags for framework and core-nodes to link to in recipes.
• [x] Restore build config matrix for linux/osx and python versions
• [x] Fork staged-recipes and upload our new recipe for testing.

[borupdaniel]

@aganders3 I want to move discussion here rather than on a random commit.

If you want to test where we're at, you can install gpi=1.1.1rc4 and gpi_core from my channel (danielborup) on anaconda.

I'm playing with this now, and I actually like the idea of keeping the full library name (like gpi_core) when browsing nodes within GPI. It makes it clear which nodes are "official" in that they're packaged on conda-forge, and makes clear what name needs to be passed if someone wants to import those packages elsewhere. There are a few places in our internal MRTUD repo, for example, that have an import core statement that we'll need to change — this is less obvious if the node library still showed up as core within GPI.

(unrelated, but another cool benefit of this setup is that we can include any other library packaged on conda-forge as a downstream in the framework build recipe so that it will build and test any time the framework is changed — nice feature especially for checking that framework changes don't break the core nodes).

[aganders3]

I'm playing with this now, and I actually like the idea of keeping the full library name (like gpi_core) when browsing nodes within GPI. It makes it clear which nodes are "official" in that they're packaged on conda-forge, and makes clear what name needs to be passed if someone wants to import those packages elsewhere. There are a few places in our internal MRTUD repo, for example, that have an import core statement that we'll need to change — this is less obvious if the node library still showed up as core within GPI.

Yeah I guess that's fine - still a bit strange to me if you want to keep a dev version as well since it will have to go in ~/gpi/gpi_core but I can get over that.

[borupdaniel]

Yeah I guess that's fine - still a bit strange to me if you want to keep a dev version as well since it will have to go in ~/gpi/gpi_core but I can get over that.

What if we have the framework create a directory like ~/gpi/packaged_nodes that contains symlinks to the site-packages folders without the gpi_ prefix? Then we could leave the node library names and import/include statements alone, right?

[aganders3]

I think that's overcomplicating it. I think there are benefits to doing it this way and the only cons so far are the friction to change and a slight aesthetic preference.

[borupdaniel]

Sounds good — will go forward with this!