CMake should not make changes to bashrc or other global files outside of the context of *building* nupic and nupic.core. Meanwhile, the codebase should be concerned as little as possible with special-casing specific platforms.
Austin, have you read the entire post where I say this was a previous suggestion but I listen Utensil ? On 11 April 2014 12:30, Austin Marshall <[email protected]> wrote: > CMake should not make changes to bashrc or other global files outside of > the context of *building* nupic and nupic.core. Meanwhile, the codebase > should be concerned as little as possible with special-casing specific > platforms. > > There are two platform-specific repositories ( > https://github.com/numenta/nupic-linux64 and > https://github.com/numenta/nupic-darwin64) that are meant to mitigate any > issues related to platform special cases, and I'd rather see the effort put > into those projects. Those are provided as an option, but also to help > things internally at Numenta. For the very latest, see the python-2.7 > branches which will be merged into master very soon. > > For those reasons, I'm thumbs-down on > https://github.com/numenta/nupic/pull/801 > > > 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 > > -- 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
