It's just create a setup.py calling cmake process.. It's not need change anything in the current process...
> I want to add my support to moving towards using setup.py, so we can distribute via pip. On 11 April 2014 14:46, Chetan Surpur <[email protected]> wrote: > +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 > > -- 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
