+1 (fully agree) I want to add my support to moving towards using setup.py, so we can distribute via pip.
On Fri, Apr 11, 2014 at 9:58 AM, Subutai Ahmad <[email protected]> wrote: > > OK, so I think the spirit of this proposal is excellent but I don't think > this mechanism will work in general. Also, it's not a standard way of doing > things. > > To see why it would not work consider this: I should be able to login to > my home directory, type python, and then do "import nupic". It is necessary > to support this. Unless the NuPIC release is *placed* in a standard > location, python will have no idea where nupic is. > > We also need to support a third type of user, which will eventually be the > most common type of user: the user who does NOT clone the repo but instead > just downloads a binary package. > > The standard unix/linux workflow for all this is: > > 1) build step started from the root of the repository. By default this > build step puts all generated files inside the repository, but there is an > optional argument if you want to place the build files somewhere specific. > In python this is done through "setup.py". In C++ this is usually just > "configure" and "make". We will use cmake for c++ but eventually may need > to use setup.py for python (setup.py will just call cmake). > > 2) an install step started from the root of the repository. By default the > install step puts all generated files inside standard locations, such as > /usr/local/... In this case you need sudo access. There is also an optional > --prefix argument if you want to put the release files somewhere specific. > In python this is done through setup.py. In C++ this is "make install". > > 3) Optional test step. This is run from the root of the repository and > assumes everything is in the standard locations. It can take optional > arguments for non standard installs. > > I think we should move towards this standard workflow. This does not > require environment variables for those who follow the standard install > process. It also doesn't need any special cases in the code itself. It does > not touch .bashrc or your global environment. If you need more > sophisticated environments you have the option of setting variables. > Temporarily, we could override if $NUPIC or $NTA is set, but ultimately > these will also not be necessary. > > It also supports the third type of user mentioned above. They just need to > run the install step from the downloaded package. > > --Subutai > > > > On Fri, Apr 11, 2014 at 9:35 AM, David Ragazzi <[email protected]>wrote: > >> > "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? >> >> Yes, exactly, Subutai! (except that default locations maybe don't need >> are platform specific, i.e. taking "build/release" as default location for >> $NTA, for example).. IMO this new process saves time of configurarion, >> don't confuse newbies, and still avoids a serious problem: suppose I move >> my repo to another folder or even other machine.. with the current state of >> process, I should set $NUPIC and $NTA again.. on the contrary, the binaries >> will be generated to the old folder.. With the new process, eveything is >> done in an automatic way, without need user intervention! >> >> >> On 11 April 2014 13:01, Subutai Ahmad <[email protected]> wrote: >> >>> >>> 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 >>> >>> >> >> >> -- >> 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 > >
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
