-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Pythonic build: Switch from cmake to distutils extensions for nupic installation #1579
Conversation
CC: @rhyolight @oxtopus |
Update: I've found these Python tests which are very similar to HtmTest: https://github.com/numenta/nupic/blob/master/tests/integration/py2/nupic/engine/network_testnode_interchangeability.py I'm serioulsy thinking in remove it as it sounds very redundant. |
311ad29
to
7d446d6
Compare
if not os.path.exists(destDir): | ||
os.makedirs(destDir) | ||
|
||
response = urllib2.urlopen(url) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Davidragazzi You have to handle all HTTP errors here. No matter what the error, print a warning and proceed with a local clone and build of nupic.core
.
Here is the error I'm getting on darwin:
Looks like |
Yes, |
commonObjects = [ | ||
nupicCoreReleaseDir + "/lib/" + self.getStaticLibFile("nupic_core"), | ||
nupicCoreReleaseDir + "/lib/" + self.getStaticLibFile("gtest"), | ||
nupicCoreReleaseDir + "/lib/" + self.getStaticLibFile("gtest"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicate line.
Please see david-ragazzi#41 That builds for me on my laptop with caveats. For some reason, by default "-arch x86_64 -arch i386" is passed to clang, which causes compiler errors:
As far as I can tell, the only way around it is to set the env var, which is not ideal. |
Hey @david-ragazzi I'd like to work on this PR tomorrow (in about 8 hours). If you have local changes that are worth pushing, try to push them before then. If you're online, maybe we can work together. |
@oxtopus said:
Ah ok.. This answered my question in david-ragazzi#41 (comment)... I'll merge your PR now.. By the way, we still need solve this ARCH env var and avoid this. I see now that you agree that this is not ideal. So we could put a #TODO as @rhyolight suggested until we solve the other issues. |
It's ok for me however I'm not on my machine now, so I couldn't help pushing directly code until go home (11 am - Los Angeles time) but merging PRs into my branch and helping to solve issues until there. About this, could someone solve the merge conflicts on this PR and then send a new PR to I update my branch? |
@david-ragazzi said:
|
Current status for local darwin build: http://pastebin.com/NtDGg2Fi Basically, this error over and over:
|
@rhyolight That is the issue that requires setting the ARCHFLAGS env variable as I described. It's not happy with the |
@oxtopus Got it. I updated this PR with a new TODO item so we don't forget it. |
@david-ragazzi I'm going to start by adding HTTP error handling logic when trying to pull in |
|
||
|
||
def skipPyCompile(self, file, cfile=None, dfile=None, doraise=False): | ||
filesToSkip = ["UnimportableNode.py"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oxtopus Didn't you take care of this in a recent PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I did, and it no longer needs to be skipped.
Hi guys, as we are in a Python environment, could be possible set temporary ARCH in runtime using |
# | ||
if sys.version_info < (2, 7): | ||
print "FATAL_ERROR: Only these versions of Python are accepted: 2.7 or later" | ||
sys.exit() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of this printout and exit, I think I'd rather raise an Exception for things we define as "fatal". I'll include in a PR I'm working on.
@david-ragazzi david-ragazzi#51 pulls in the latest changes from master after I pushed 0.1. It includes a big README simplification, but your |
Merges in master with 0.1 README
Ok, it's fine. |
@scottpurdy ping! |
nupic/bindings/*.cxx | ||
nupic/bindings/proto/*.capnp | ||
nupic/bindings/ | ||
~nupic/bindings/*.i |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is ~nupic
? I'm not convinced that I want this hidden from me if it gets created
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
~
= not
, so these lines mean ignoring all files in nupic/bindings/
, except *.i
files.
A couple questions but I think this is good. @oxtopus was happy and I wanted to make sure that we are fitting all of our compilation steps into the "extension" framework which it looks this does cleanly. @david-ragazzi - thanks for sticking with this one! Big change but will be very nice if we can keep this working for source or binary installations on different platforms. |
Oh and to be clear, big 👍 |
@david-ragazzi Please respond to Scott's comments and take a look at https://github.com/numenta/nupic/wiki/NuPIC's-Dependency-on-nupic.core... does this wiki need to be updated along with the merge of this PR? |
Done.
Yeah, we need update wiki with removal of CMake after this is merged. |
Pythonic build: Switch from cmake to distutils extensions for nupic installation
Fixes: numenta#1573 It's weird.. I simply don't undertand why this file still is in repository. I thought I had removed it through numenta#1579
…le, dir, etc.) as well as minor alignment issues
Cleanup re: numenta#1579. Fixup namespace conflicts with builtins (file, dir, ...
Pythonic build: Switch from cmake to distutils extensions for nupic installation
Fixes: numenta#1573 It's weird.. I simply don't undertand why this file still is in repository. I thought I had removed it through numenta#1579
Fixes #1573.
This PR aims to help we have Nupic "pip installable". For this it tries to leave the build/install process the more "pythonic" as possible using:
a) native support from Distutils/SetupTools to build all C++ extensions (#1573)
b) Python scripts to perform jobs that were being performed by C++ executables (#1576).
The motivation of B is because it's very tricky install all current cpp executables and libraries using A solution. Some of these libraries (like
bindings
) are inevitable to be build as extensions, however c++ extensions likehtmtest
andcompare_nupic_core_version
can be replaced to python scripts. Different than bindings, these 2 extensions are complicating the process as they should be installed into souce repository (bin
folder, to be exact) and not intonupic
package install folder like the other modules.Once that all extensions now can be build in a natural way, we can remove CMakeLists.txt from NuPIC Pyhton. This makes that CMake becomes essential only to build the NuPIC Core library: as this is an optional job, we could bypass CMake/Git use during PIP process decreasing the number of build/install steps and dependencies.
I still am working on the pythonic version of
HtmTest
. Thus it's normal that some tests fail, because Travis still is referencing its c++ version.TODO:
ARCHFLAGS="-arch x86_64"
requirement on darwin64. Update: There's not way, distutils take the flags which python was build. So we cannot set this variable insidesetup.py
.make
commands to python instructions andcustom_targets
remotion) to a new PR. Solved by Pythonize the tests calls #1622python setup.py --help
&python setup.py --help-commands
should print help, not compile