As a sway developer, I want the codebase to default to local IP settings

[morphogencc]

Wouldn't it make sense to have the default configuration settings be such that it could run on your local machine?

That way a potential user could clone the repo and have it up and running without fudging around with config files.

[JimAnkrom]

Yes; we've had it set to config for current production config so to minimize risk when hotfixing at art installations.

I think building in a dev / test / prod config environment would be the best way to handle this, but setting to localhost would be ok.

I'd leave the ports as-is though.

[morphogencc]

Fair points!

nathan

On Wed, Oct 8, 2014, at 12:10 AM, JimAnkrom wrote:

Yes; we've had it set to config for current production config so to minimize risk when hotfixing at art installations.

I think building in a dev / test / prod config environment would be the best way to handle this, but setting to localhost would be ok.

I'd leave the ports as-is though.

---

Reply to this email directly or view it on GitHub: https://github.com/JimAnkrom/sway/issues/54#issuecomment-58305949

[JimAnkrom]

API could load a "sway.env.json" which has a property "current", which has values 'dev', 'test', or other installation configurations.

This could be then concatenated into the next require statement like so: var swayEnvironment = require('sway.env.json'); var swayConfig = require('sway.config.' + swayEnvironment.current + '.json');

[Dewb]

Easy way to address this in the short term is use npm config / package.json configuration variables. You can put the defaults in package.json, and then override them via the command line.

See this page on the npm config command: https://www.npmjs.org/doc/cli/npm-config.html

and the "Per-Package Config Settings" section here: https://www.npmjs.org/doc/misc/npm-config.html

[Dewb]

With that setup, you could satisfy both of the stated scenarios: the repo would work "out of the box" for the default art-deployment, but one or two commands could make it work on a different machine, no file editing required.

On the other hand, it might make more sense to have localhost be the default set in package.json, and for deployments to issue command(s) to set the correct address(es). Local npm config is sticky so, depending on how you deploy physical source updates, you might only need to do it once.

[JimAnkrom]

Oh, cool, thanks! I should RTF-npm-M much more than I have had chance to.

I think at some point, though, this may become moot as the concept of a 'default art-deployment' and subsequent config needs will be refactored out of sway as a platform and into consumers of sway. But this will definitely be useful in the interim - and then later in the resulting consumer code.

In my mind that separation of platform vs (art) installation concerns is a pretty near-term goal, it's becoming more and more obvious where the customization endpoints need to be (such as input sources, control data translation/transformation, output destinations) and how critical it is to separate them to allow sway's platform to support sway's many possible applications.

[Dewb]

Side note: you probably want some examples in the main Sway repo.

[morphogencc]

Absolutely need some examples -- I think that the ui folder serves as a sort-of example as of now, though (and can easily be split off later).

nathan

On Wed, Oct 8, 2014, at 01:20 PM, Michael Dewberry wrote:

Side note: you probably want some examples in the main Sway repo.

---

Reply to this email directly or view it on GitHub: https://github.com/JimAnkrom/sway/issues/54#issuecomment-58393620

[JimAnkrom]

I anticipate factoring out a recipe or two in the sway repo that include examples of the common input sources (orientation, motion, position, touch/swipe), transformation (range, scale), and output sources (OSC, maybe websockets), a baseline config to tie them together, and a hello world UI to bootstrap the lot.

Can git fork off of a subset of a repo (like, fork just a folder)? If so I'll fork off an implementation repo from that recipe, otherwise I'll just copy it over to a new repo and roll with that.

[morphogencc]

You could always keep a separate branch for the examples / recipes and keep working on the codebase in your main branch.

nathan

On Wed, Oct 8, 2014, at 01:39 PM, JimAnkrom wrote:

I anticipate factoring out a recipe or two in the sway repo that include examples of the common input sources (orientation, motion, position, touch/swipe), transformation (range, scale), and output sources (OSC, maybe websockets), a baseline config to tie them together, and a hello world UI to bootstrap the lot.

Can git fork off of a subset of a repo (like, fork just a folder)? If so I'll fork off an implementation repo from that recipe, otherwise I'll just copy it over to a new repo and roll with that.

---

Reply to this email directly or view it on GitHub: https://github.com/JimAnkrom/sway/issues/54#issuecomment-58396451

[JimAnkrom]

Hmm... that doesn't smell right to me.

Branching should be for version-specific variation, not for variation in same version product. Branching for a variants of the same version would make for bugfix merge nightmares.

...I think. I need to put more thought in this, but that has never been proposed in any of the best practices I've read for other SCM's.

On Wed, Oct 8, 2014 at 1:42 PM, nathan lachenmyer notifications@github.com wrote:

You could always keep a separate branch for the examples / recipes and keep working on the codebase in your main branch.

nathan

On Wed, Oct 8, 2014, at 01:39 PM, JimAnkrom wrote:

I anticipate factoring out a recipe or two in the sway repo that include examples of the common input sources (orientation, motion, position, touch/swipe), transformation (range, scale), and output sources (OSC, maybe websockets), a baseline config to tie them together, and a hello world UI to bootstrap the lot.

Can git fork off of a subset of a repo (like, fork just a folder)? If so I'll fork off an implementation repo from that recipe, otherwise I'll just copy it over to a new repo and roll with that.

---

Reply to this email directly or view it on GitHub: https://github.com/JimAnkrom/sway/issues/54#issuecomment-58396451

— Reply to this email directly or view it on GitHub https://github.com/JimAnkrom/sway/issues/54#issuecomment-58396978.

[morphogencc]

I mean, isn't variant in same version product what you do when you branch off a version of your codebase, fix a bug, and then submit a pull request to integrate the fix?

And when 5 people are adding features simultaneously... they usually just keep working on different branches, and then merge them back.

nathan

On Wed, Oct 8, 2014, at 01:47 PM, JimAnkrom wrote:

Hmm... that doesn't smell right to me.

Branching should be for version-specific variation, not for variation in same version product. Branching for a variants of the same version would make for bugfix merge nightmares.

...I think. I need to put more thought in this, but that has never been proposed in any of the best practices I've read for other SCM's.

On Wed, Oct 8, 2014 at 1:42 PM, nathan lachenmyer notifications@github.com wrote:

You could always keep a separate branch for the examples / recipes and keep working on the codebase in your main branch.

nathan

On Wed, Oct 8, 2014, at 01:39 PM, JimAnkrom wrote:

I anticipate factoring out a recipe or two in the sway repo that include examples of the common input sources (orientation, motion, position, touch/swipe), transformation (range, scale), and output sources (OSC, maybe websockets), a baseline config to tie them together, and a hello world UI to bootstrap the lot.

Can git fork off of a subset of a repo (like, fork just a folder)? If so I'll fork off an implementation repo from that recipe, otherwise I'll just copy it over to a new repo and roll with that.

---

Reply to this email directly or view it on GitHub: https://github.com/JimAnkrom/sway/issues/54#issuecomment-58396451

— Reply to this email directly or view it on GitHub https://github.com/JimAnkrom/sway/issues/54#issuecomment-58396978.

---

Reply to this email directly or view it on GitHub: https://github.com/JimAnkrom/sway/issues/54#issuecomment-58397881

[JimAnkrom]

Yes, those are called 'feature branches'. Feature branches aren't usually destined for releases on their own though, they are intended to be merged into a release branch. They aren't (usually) standalone features, either, and usually are not themselves branched.

This is not a 'features of sway' concept - it is a customization of sway. IMO it's best to tie customizations to a specific core version, not create branches (versioned timelines) for each customization. I worked for company-who-shall-remain-nameless that did that, and it was a simply majestic new level of hell - not just a new branch for each customer, but a new branch for each customer per new branch for each core release. Maintenance releases become impossible.

On Wed, Oct 8, 2014 at 1:53 PM, nathan lachenmyer notifications@github.com wrote:

I mean, isn't variant in same version product what you do when you branch off a version of your codebase, fix a bug, and then submit a pull request to integrate the fix?

And when 5 people are adding features simultaneously... they usually just keep working on different branches, and then merge them back.

nathan

On Wed, Oct 8, 2014, at 01:47 PM, JimAnkrom wrote:

Hmm... that doesn't smell right to me.

Branching should be for version-specific variation, not for variation in same version product. Branching for a variants of the same version would make for bugfix merge nightmares.

...I think. I need to put more thought in this, but that has never been proposed in any of the best practices I've read for other SCM's.

On Wed, Oct 8, 2014 at 1:42 PM, nathan lachenmyer notifications@github.com wrote:

You could always keep a separate branch for the examples / recipes and keep working on the codebase in your main branch.

nathan

On Wed, Oct 8, 2014, at 01:39 PM, JimAnkrom wrote:

I anticipate factoring out a recipe or two in the sway repo that include examples of the common input sources (orientation, motion, position, touch/swipe), transformation (range, scale), and output sources (OSC, maybe websockets), a baseline config to tie them together, and a hello world UI to bootstrap the lot.

Can git fork off of a subset of a repo (like, fork just a folder)? If so I'll fork off an implementation repo from that recipe, otherwise I'll just copy it over to a new repo and roll with that.

---

Reply to this email directly or view it on GitHub: https://github.com/JimAnkrom/sway/issues/54#issuecomment-58396451

— Reply to this email directly or view it on GitHub https://github.com/JimAnkrom/sway/issues/54#issuecomment-58396978.

---

Reply to this email directly or view it on GitHub: https://github.com/JimAnkrom/sway/issues/54#issuecomment-58397881

— Reply to this email directly or view it on GitHub https://github.com/JimAnkrom/sway/issues/54#issuecomment-58398780.

[Dewb]

How do you expect consumers of Sway will use Sway to build things? Repo/file system setup, etc. In the long term, do that for Bleep stuff.

In the short term, Bleep test apps could easily be prototypes of examples in this repo.

[morphogencc]

Ah. I see what you're saying the difference is.

It seems, then, that the best way to organize it is to have all of the sway core in its own folder that just contains the source and no actual applications.

And then each application has a configuration file that points it to the path for sway.

This also allows you to have multiple versions of sway installed, and have each application just pointing towards a specific version/release of sway on your machine.

or am i misunderstanding the problem?

nathan

On Wed, Oct 8, 2014, at 02:02 PM, JimAnkrom wrote:

Yes, those are called 'feature branches'. Feature branches aren't usually destined for releases on their own though, they are intended to be merged into a release branch. They aren't (usually) standalone features, either, and usually are not themselves branched.

This is not a 'features of sway' concept - it is a customization of sway. IMO it's best to tie customizations to a specific core version, not create branches (versioned timelines) for each customization. I worked for company-who-shall-remain-nameless that did that, and it was a simply majestic new level of hell - not just a new branch for each customer, but a new branch for each customer per new branch for each core release. Maintenance releases become impossible.

On Wed, Oct 8, 2014 at 1:53 PM, nathan lachenmyer notifications@github.com wrote:

I mean, isn't variant in same version product what you do when you branch off a version of your codebase, fix a bug, and then submit a pull request to integrate the fix?

And when 5 people are adding features simultaneously... they usually just keep working on different branches, and then merge them back.

nathan

On Wed, Oct 8, 2014, at 01:47 PM, JimAnkrom wrote:

Hmm... that doesn't smell right to me.

Branching should be for version-specific variation, not for variation in same version product. Branching for a variants of the same version would make for bugfix merge nightmares.

...I think. I need to put more thought in this, but that has never been proposed in any of the best practices I've read for other SCM's.

On Wed, Oct 8, 2014 at 1:42 PM, nathan lachenmyer notifications@github.com wrote:

You could always keep a separate branch for the examples / recipes and keep working on the codebase in your main branch.

nathan

On Wed, Oct 8, 2014, at 01:39 PM, JimAnkrom wrote:

I anticipate factoring out a recipe or two in the sway repo that include examples of the common input sources (orientation, motion, position, touch/swipe), transformation (range, scale), and output sources (OSC, maybe websockets), a baseline config to tie them together, and a hello world UI to bootstrap the lot.

Can git fork off of a subset of a repo (like, fork just a folder)? If so I'll fork off an implementation repo from that recipe, otherwise I'll just copy it over to a new repo and roll with that.

---

Reply to this email directly or view it on GitHub: https://github.com/JimAnkrom/sway/issues/54#issuecomment-58396451

— Reply to this email directly or view it on GitHub https://github.com/JimAnkrom/sway/issues/54#issuecomment-58396978.

---

Reply to this email directly or view it on GitHub: https://github.com/JimAnkrom/sway/issues/54#issuecomment-58397881

— Reply to this email directly or view it on GitHub https://github.com/JimAnkrom/sway/issues/54#issuecomment-58398780.

---

Reply to this email directly or view it on GitHub: https://github.com/JimAnkrom/sway/issues/54#issuecomment-58400200

[JimAnkrom]

"How do you expect consumers of Sway will use Sway to build things? Repo/file system setup, etc. "

Ooh, that's a good way to frame the problem. It makes me think consumer may be the wrong terminology; services are consumed, frameworks are plugged-into.

I believe someone implementing sway would configure it to use existing (OOTB) or customized input/output/transformation plugins - which then is a service that their custom UI consumes. This implies to me that (1) we need to formalize a plugin framework (there's some work to that end) and (2) we need an OOTB plugins folder outside of core.

This also raises (3) - a majoritiy of current UI as it stands today may not be considered core.

Nathan - I believe you've got it now.

[Dewb]

There are probably two directions forward here -- either Sway is a container for everything you want to do to build your app (plugins, config files, whatnot) or Sway is a library that you add to your project with npm install. Former is easier for initial development but I suspect we eventually may prefer the latter.