papr: make into proper Python package #50
Conversation
This is a start towards converting the codebase to Python. No big rewrite in this patch yet, just restructuring everything to follow a predictable typical Python app. We start using setuptools to actually install the app rather than running straight from the source tree. This also introduces versioning of the app. Although we've been around for some time now, let's start at v0.1.
And move documentation files into them.
And soon, we'll bump this again to Fedora 26...
It's actually pretty good at finding more subtle issues.
|
💥 Invalid |
| @@ -1,4 +1,4 @@ | |||
| FROM fedora:24 | |||
| FROM registry.fedoraproject.org/fedora:25 | |||
There was a problem hiding this comment.
When I initially wrote this commit, F26 wasn't released yet. I'll bump to fedora:26 in the next PR once I have a chance to test it out.
|
One thing I'd consider is basing this on https://docs.openshift.com/container-platform/latest/using_images/s2i_images/python.html I'm tempted to do that for Homu too. The thing is - a year from now, do you want to be spending your time rebasing and testing on Fedora N+1 for all the apps you write? |
|
That's an interesting idea I hadn't considered. Will give it a try, though I don't foresee issues as long as the Python env is the same. |
|
Had a closer look at this, and it feels really awkward to use if you're not yet running on OpenShift and have easy access to S2I. Though I really like the idea of basing on CentOS and hardcoding the Python version. I did the equivalent non-S2I thing and tried reworking it to use |
|
Doing local dev with openshift is why |
|
It's mostly up to you of course, but there's really a reason OpenShift emphasizes RHEL + SCLs; few people want to rebase their apps every 6 months. They more want a stable base with security updates, but they do want newer stacks of selected things (what SCLs do). At the scale our team is at it probably doesn't really matter, but if we had more than just two apps it'd likely start to matter more. |
|
No, it's a fair point. And that's definitely what I want as well for PAPR (stable base + security fixes). I'd just prefer to spend time on this after the rewrite at least so we can take it one step at a time. Does that work? Any feedback on the rest of the PR otherwise? I'd like to get this in since I've got lots more pending! |
|
I opened #51 to track this. |
|
Ah sorry forgot to mention, I gave this a high level scan, and it LGTM! |
|
Thanks! Autosquashed and merged manually! |
This is a start towards converting the codebase to Python. No big
rewrite in this patch yet, just restructuring everything to follow a
predictable typical Python app. We start using
setuptoolsto actuallyinstall the app rather than running straight from the source tree.
This also introduces versioning of the app. Although we've been around
for some time now, let's start at v0.1.
Splitting this out of my work tree to make it easier to review and test. I've successfully tested this in the sandbox.