Updates for deployment and maintanibility #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 30 commits
March 25, 2017 15:57
We can create a deployment artifact later, if we want, but for the sake of version control and many people potentially working on things at once, we need all the source to live in the repo directly.
The end goal is to have the code generalized enough that it can be built as a pip package and server though pypi. This will make it much easy for many people to contribute to the project, and will allow for an easy distribution and upgrade mechanism.
these things already are part of picontrol, so they don't need picontrol in their names themselves. This also will make importing better. Rather than `import picontrol.picontrol_nfc as nfc` it becomes `from picontrol import nfc`. Much more pythonic and clean. This subsiquently updates a lot of imports because of these changes This also makes a few of the files executable, as they are the various entry points into the program. The files are: fan.py. picontrol.py button_classic.py button_pi.py and picontrol_web.py
This will automatically be installed the system path so they can be run from anywhere without knowing the specific location
This relies on this package being pip installable and listed in pypi, which it will be shortly. Also this adds gamestart and gameend to the setup.py scripts
Configs should live in a separte location from source code. In this case we will put it in the root project directory, but will expect them to live in the ".picontrol" direcotry in the users home. This is very standard for many systems like this. It will also read from the old configs location, but will not write to it anymore, and will not read the old location if the new location exists.
Before it was relying on the distribution file in the git repo to be updated from time to time, and would actually download the file every time it even wanted to check for an update. Now we just as pip if there is an update, and if there is we install it. Super simple.
Also a few whitespace fixes as well
Now config.py is "the one place" for getting information about the configs. This means if we need to change things about the way we are doing comfigs, we only need to modify this file. No more copying and pasting into multiple locations. Also, with statements when manually opening files saves lots of headaches. Additionally, some whitespaces cleanup.
Ensure we have 666 permissions so anyone can read/write. It would be better to have more restricted permissions, but, for now, that isn't possible due to the way everything is being run.
This means, we will have default values if the config doesn't exists, and the config will be written for the user automatically. In the end this means putting the configs in the correct location is no longer needed as an install step.
Also update the README.md to reflect new install instructions
It eventually will run tests, but for now it just lets the build proceed
They are more portable, and work better in general. This also adds a main function to all related files, as is currently where the entrypoints point to.
The picontol.py name particuarly was interfering with some of the entry_points
I got over zealous in my removal of some versioning logic, which cause the version to not properly show up.
I forgot they either need the list format, or shell=True
Now both parts use `pip search` for checking as it gives all the needed information
The error messsage was, unforunately, getting swollowed. Hopefully soon we can go though and fix all the super general except: blocks Also update and simplify versioning
It doesn't need to be executable anymore, so lets have it not be
Because we aren't nessesarly running in sudo, though we can somewhat safely assume the process running has sudo privliges Also, a few tweeks to the setup.sh script
Also, make setup.sh executable for easier running
Add correct download location for this fork, and build status
Particularly we need to use a user path, as we don't actually have /etc/ permissions, as this is ran in an unprivilaged mode. Instead we store the config in a .picontrol in the executers home directory. By default the executer is (for now) the pi user.
This version of picontrol.tgz is built exclusivly to be a bridge between the pypi deployed versions of picontrol, and the old only github deployment. It basically contains part of the newer upgrade logic, along with a custom upgrade script to help migrade assets over to the new version.
For the sake of not breaking some existing instructions, we will keep these with the same names as they had originally
Collaborator
Author
|
I have added |
I missed the last set of changes in it, particularly the version file
Collaborator
Author
|
To fully test this, you need to update your the download location From there you can go through the webui update process twice (once to update to the new picontrol.tgz, and a second time to update to the pypi version). Once that is finished you should be on version 1.1, which is the pypi version and should be running as before. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The core concept of this pull request is to get the code building in https://travis-ci.org and deploying automatically to pypi upon a tagged release (a git tag of some version, like "0.9"). So picontrol is now pip installable.
I really wanted to be able to make changes to this code as needed, but because the source was all contained inside the tgz, not in the actual repo, it would have made things very hard. Instead, if the source lives in the repo directly, we can get all the benefits of source code management, including easy collaboration.
There are many improvements to logic in this, but one of the bigger ones is how updating happens. Because the code is now deploying to pypi, all that needs to happen is a
pip install -U picontroland the code gets updated. Additionally, this means we can use pip to check if we need an upgrade or not, using thepip listcommand.Also, a bit of work was done to the config system. First, in an effort to generalize things a bit, the main config now lives at
/etc/picontrol/picontrol.confThis should help things to be a bit more portable. Configs in the old location will still be checked if the etc config doesn't exist, but changes/saves will be done to the etc location. Additionally, the default config has been build into the config.py code, so a base config no longer needs to ship with the code. It will be auto-generated on the first run. As the config that was storing the processes running is transient (deleted every time we restart the machine) it is now created in the/tmpfolder, and again, is create at run time.One big caveat to this is that this will break the existing upgrade functionality, as in, code running on a system right now will not be able to upgrade to this new version. To this, I have a fix in mind, where one last
picontrol.tgzwould be created which contains the new upgrade logic, and new code could, in turn, upgrade to the pip based version. It would basically require two upgrades in a row for people on the old version, but should work no problem.One small issue is that I haven't been able to test with the hardware (switches/nfc) as I haven't gotten my kit yet, but I have been testing extensively on my rpi3, and so far everything is looking good.
I will update this pull request once I have created the in-between
picontrol.tgzand then we can go from there.