Makefile rules do not match documentation
Closed this issue · 11 comments
The documentation does not match up to the Makefile; for example there is no "setup" rule.
We need to either correct the documentation or update the Makefile.
Hi Mike,
Agreed. The main question is: how many folks actually do a build on MAC or PC?
With kind regards,
Michel Kohanim
CEO
(p) 818.631.0333
(f) 818.436.0702
http://www.universal-devices.comhttp://www.universal-devices.com/
From: Mike Westerhof [mailto:notifications@github.com]
Sent: Wednesday, March 30, 2016 8:29 PM
To: UniversalDevicesInc/Polyglot Polyglot@noreply.github.com
Subject: [UniversalDevicesInc/Polyglot] Makefile rules do not match documentation (#28)
The documentation does not match up to the Makefile; for example there is no "setup" rule.
We need to either correct the documentation or update the Makefile.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/28
It's probably important for us to know if we really need to build for specific platforms, or if it is sufficient for us to distribute a pure-python (no binaries) release? Note that we can still release as a simple single python "pyz" self-extracting file without using Cython to generate the binaries.
o, a question for UDI:
Was the original intent of doing a binary build and release simply to avoid releasing the Python sources, or is there a performance consideration as well?
If the former, we can probably avoid having to maintain separate build machines, and simply define a single standard configuration (python and python packages versions) for the construction of the pyz distribution file.
If the latter, then we should publish that information so that users who pull from github and run the pure python (rather than the binaries) know what they may be compromising in terms of performance or support or whatever the impact is.
Hi Mike,
Excellent question!
The reasons for going with binary were first and foremost: support and security. i.e. if everything is in clear text, everyone can simply take the codebase, make modifications, and then release it without proper testing and then we would have to deal with configuration issues not to mention plugins that might jeopardize security in one way/shape or form.
When we started this project, we were considering making it into a product that can eventually be sold with:
a) Fully supported product just like ISY
b) Development tools for developers
c) Have a vetting process to test plugins and developers since the adhoc mode would cause major support issues
d) Poly Store where plugins can be published and purchased
e) Agreements with developers for remuneration and support
On the other hand – and taking into consideration the success of Node.js and NPM (the largest repository of open source modules in the world) – it seems that making development and usage too restrictive may have a negative impact.
So, having said all this, I believe that currently the best approach would be to:
-
Keep it simple and thus no binaries for now -
Find all the missing requirements for ISY by developing various plugins such as the ones James has created (Sonos) and see what’s missing and what needs improvements -
Figuring out the best configuration approach … currently, configurations are done through ISY. Perhaps a combined UI for both ISY/Polyglot that will help with configuration -
Once we have 10 polys then – and as the core Polyglot team – we can decide the best approach going forward
My questions to the team:
-
Your thoughts between full open source vs. a Poly Store, supported product, and remunerations for developers -
Should we invite more developers (I can send a mass email to all those who have registered as Developer)?
I want to thank each and every one of you for your contributions. And, I am very proud to be working with you.
Thanks again.
With kind regards,
Michel Kohanim
CEO
(p) 818.631.0333
(f) 818.436.0702
http://www.universal-devices.comhttp://www.universal-devices.com/
From: Mike Westerhof [mailto:notifications@github.com]
Sent: Thursday, March 31, 2016 8:16 AM
To: UniversalDevicesInc/Polyglot Polyglot@noreply.github.com
Cc: Michel Kohanim michel@universal-devices.com
Subject: Re: [UniversalDevicesInc/Polyglot] Makefile rules do not match documentation (#28)
It's probably important for us to know if we really need to build for specific platforms, or if it is sufficient for us to distribute a pure-python (no binaries) release? Note that we can still release as a simple single python "pyz" self-extracting file without using Cython to generate the binaries.
o, a question for UDI:
Was the original intent of doing a binary build and release simply to avoid releasing the Python sources, or is there a performance consideration as well?
If the former, we can probably avoid having to maintain separate build machines, and simply define a single standard configuration (python and python packages versions) for the construction of the pyz distribution file.
If the latter, then we should publish that information so that users who pull from github and run the pure python (rather than the binaries) know what they may be compromising in terms of performance or support or whatever the impact is.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHubhttps://github.com//issues/28#issuecomment-203982479
Making money aside. If we want it to take off we need to get a clean product available, and like I found out yesterday, having a product that 'just works' is important. If anything we should create a binary so that people can just run it. I don't have a problem with leaving the pure python available as well for devs, but we need an ease of deployment.
For example we can have a compiled 'master' and compiled 'dev'. It's not that hard to build it when you finish testing and just merge the binary like everything else.
That way people can start actually using the product.
Hi James,
I do like the idea very much. This said, I do not think we have enough plugins such that people can simply deploy. We are all developers.
In order to make it into a product, we (UDI) must make a productized and tested version of RPi which can be supported.
This said, I do not mind creating two branches: one production and one development.
With kind regards,
Michel Kohanim
CEO
(p) 818.631.0333
(f) 818.436.0702
http://www.universal-devices.comhttp://www.universal-devices.com/
From: James [mailto:notifications@github.com]
Sent: Thursday, March 31, 2016 12:09 PM
To: UniversalDevicesInc/Polyglot Polyglot@noreply.github.com
Cc: Michel Kohanim michel@universal-devices.com
Subject: Re: [UniversalDevicesInc/Polyglot] Makefile rules do not match documentation (#28)
Making money aside. If we want it to take off we need to get a clean product available, and like I found out yesterday, having a product that 'just works' is important. If anything we should create a binary so that people can just run it. I don't have a problem with leaving the pure python available as well for devs, but we need an ease of deployment.
For example we can have a compiled 'master' and compiled 'dev'. It's not that hard to build it when you finish testing and just merge the binary like everything else.
That way people can start actually using the product.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHubhttps://github.com//issues/28#issuecomment-204084047
But that's just the point I was making earlier, Einstein42 -- compilation is NOT necessary in order to distribute something that "just works". The "pyz" file format is independent of the compiled binary, and can contain pure python.
I would argue that a binary distribution is going to make it much less likely that folks will be able to get frequent releases, of the mainline or the development branch. The problem is, who is going to be authorized to compile the modules, and push the compiled code to github? We can't just let anybody do that, not only might there be issues with different binaries being built by different compiler versions, etc, there's also the matter of protection from malware -- the "authorized builder" needs to be a trusted and managed machine.
So, my vote would be to drop the binaries, but keep the "pyz" format with the current list of packaged dependencies. That would keep the ease of installation that we all need, and it would also remove the strict requirements for "blessed" build machines (although we would need to specify a standard packaging machine that would generate the "pyz" file -- I'd suggest we simply spec an RPi with a virgin Raspian install to be used for this purpose; anyone can do that).
Stupid close button is like a mouse magnet. I just got a new rpi3 that is strictly used for poly dev, and I have a clean Intel Debian Linux vm I can use as well. I have a Cisco UCS c-series at the house and can deploy as many x86 vm's as you want to test. If need be I can grab some more rpi3's.
I've never compiled Python into pyz's but I suppose I can learn. Im finishing this other poly today, but I'll take the lead on code and documentation cleanup and packaging when I'm done.
I'm not opposed to buying a MacBook Pro for dev either. Gotta justify it to the wife. Unless you guys want to buy me one! Hah
If all we need to do is package the python into a pyz, we can do that on any of the supported machines; it'll be the same result. Of course, if you really want the Macbook, we won't tell your wife that! :-) (BTW, I wanted a mac just to see what all the fuss and hype was about, but found that the mac mini is a lot cheaper than the Macbook, plus it let me use the same monitor... Honestly, from a basic dev point-of-view, it's just not that different from a Linux system IMO... )
I'll take a crack at adding the rules to the makefile -- I am hopeful that we can get a dev version packaged and published really soon (just need a Kodi tester I think).
I have build environments for all three. I will build when we update unstable-release. They can have their choice.
The documentation has been updated.