NEXT icon indicating copy to clipboard operation
NEXT copied to clipboard

Update local directory to use new endpoint as in #154

Open dconathan opened this issue 9 years ago • 2 comments

I assume we're going to update the local examples to keep in step with examples, using the new endpoint.

Or better yet... is it possible to just get rid of local and make a more flexible launch.py with a --local flag that doesn't do the verify_environ(), etc.?

I could see reasons to still keep separate folders (e.g. docker_up.sh is very different for ec2 vs local)... but the docker-compose are almost identical. Would be nice to consolidate where possible, so fewer places to update when we make changes like this...

Thoughts?

dconathan avatar Jan 17 '17 18:01 dconathan

This sounds fine - I approve of two separate launch.py's. A quick question

  • is it still relevant, or can we recommend that people use the mini-gui now built in?

It's probably best to keep the docker-compose's separate unless you have a very compelling re-organization.

On Tue, Jan 17, 2017 at 1:52 PM, dconathan [email protected] wrote:

I assume we're going to update the local examples https://github.com/nextml/NEXT/tree/master/local to keep in step with examples https://github.com/nextml/NEXT/tree/master/examples, using the new endpoint.

Or better yet... is it possible to just get rid of local and make a more flexible launch.py with a --local flag that doesn't do the verify_environ(), etc.?

I could see reasons to still keep separate folders (e.g. docker_up.sh is very different for ec2 vs local)... but the docker-compose are almost identical. Would be nice to consolidate where possible, so fewer places to update when we make changes like this...

Thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nextml/NEXT/issues/165, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWhGJ2iNetfjjDNhuj0Usbaqd1JxJKWks5rTQ3UgaJpZM4LmBlN .

lalitkumarj avatar Jan 17 '17 21:01 lalitkumarj

Okay let's keep separate for now.

I'd prefer to keep supporting the launch script. This gives users a starting point to write their own launch scripts if they want to do some fancy prelaunch preprocessing. Also makes it slightly easier to find out what's happening under the hood rather than an auto-magical launch gui.

dconathan avatar Jan 17 '17 22:01 dconathan