It's a bit hard reading through the comments to understand the actual proposal. Here's what I understand so far:
This discussion is about environment variables and how they should be handled within NuPIC. This is an important discussion (thank you David for starting the discussion on the mailing list). We are talking about two variables, and only two variables. $NUPIC and $NTA. 1) $NUPIC is the location of the repository. 2) $NTA is the location of the release. The release can be placed anywhere. Specifically, it does not have to be in $NUPIC/build/release. Currently the above need to be set by the user. Now, here is the proposal as I understand it: "We would like to see if there is a way that users don't have to set any variables. The proposal is to instrument our code such that if the variables are set, we use them. If they are not set, the code uses some default locations that are platform specific." I do have opinions, but before I give any, is my understanding of all this correct? As I said before, I think this is an important discussion to have, so thank you guys for starting it! --Subutai On Fri, Apr 11, 2014 at 7:54 AM, David Ragazzi <[email protected]>wrote: > Hi everyone, > > I'm bringing this discussion to here, as asked by Utensil and Matt.. > > Recently I proposed a PR that automatically set environment variables > (specially $NUPIC and $NTA) with default variables directly into .bashrc > file. However as mentioned by Subutai, this might generate confusion in > machines that need customized configuration like those that use Grok or > others. > > Fortunatelly, Utensil drawn a scenario of our current situation which > explain some conflicting issues and how we could mitigate.. A quote: > > > There're two kinds of users: > >* Experienced nupic developers like @scottpurdy , they have been using > `$NUPIC` and `$NTA` for a long time and they preset them manually in > `.bashrc` or somewhere, and they need `$NTA` to point to somewhere other > than `$NUPIC/build/release` > > * New nupic users or developer like you and I, we intend to keep the env > var overhead minimal. > > From my understanding, I think that an ideal process it would be that > allows we would have 2 scenarios working fine: > > Scenario # 1: > > I'm a developer using NuPIC for simple software: I simply clone the repo, > run CMake, and voilá! > > Scenario # 2: > > I'm a developer using NuPIC for critical and customized software: I simply > clone the repo, *config $NUPIC and $NTA using .bashrc (or other method) > to the target locations*, run CMake and voilá! > > I really like this development workflow as this reduces steps of > configuration at same time that allows flexibility to those users that need > customization.. > > In this link you'll find further information which includes my previous > suggestion, Utensil commentary, and my plan of how the current code could > address these 2 scenarios: > > https://github.com/numenta/nupic/pull/801 > > -- > David Ragazzi > OS Community Commiter > Numenta.org > -- > "I think James Connolly, the Irish revolutionary, is right when he says that > the only prophets are those who make their future. So we're not > anticipating, we're working for it." > > _______________________________________________ > nupic mailing list > [email protected] > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org > >
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
