> >> So my problem is that while my protocol stack spins up very nicely and >> trivially easy using the twistd daemon, the standard python3-twisted package >> for 14.04 is waaaay behind and doesn't include twistd (!), and I haven't >> found a good backport. I'd also like to avoid doing things that make life >> hard for DevOps, such as pip3 installing and risking a package manager fight. > > The general solution to this problem is "don't use the system Python > environment to deploy your applications". > > This is what virtualenv is for. >
Yes, well, the standard practice around here is to wrap up deliverables in a .deb so that the DevOps tools can do automated deploys. I suppose it is possible to wrap up a venv in a .deb, but I’ve never done looked into it. Pointers welcome. >> So some options: >> - Is there a reliable backport of the python3-twisted package for 14.04? >> Google is failing me on that one. >> [...] >> - Perhaps I should create my own backport for Ubuntu 14.04 of the current >> python3-twisted .deb. (This is probably not the right list to ask, but I'm >> happy to dereference a pointer.) > > Both of these options are bad. Installing or creating a backport will break > any system tools that depend on the python3-twisted package. This is better > than `sudo pip3 install`, but only a little. > >> - All I need is the most basic twistd functionality. Perhaps I should spin >> up my own by snarfing the code out of the twisted source repo. I can >> package this with my stuff temporarily and get on with life. Clues to the >> relevant parts of the repo welcome, I haven't poked around much in Twisted >> sources so need a road map. > > If you have the ability to ship parts of the Twisted stack, there's a tool > that can automate the "snarfing": pip :-). > >> This is a short-term problem for me, we are transitioning to 16.04 soon, but >> the process is driven by other parts of the software stack. So I don't want >> to over-invest. I'm looking for a reasonable band-aid. > > 16.04 will also be out of date. So… If you would like to dive into reasons… we do robots. We use ROS, the Robot Operating System. LTS versions of ROS are tied to LTS versions of Ubuntu. Transitioning from one LTS version of ROS to another is, as they say, “non-trivial”. Being on a stale version of Ubuntu is part of the price for using ROS, because ROS just can’t move that fast. No one likes it. A lot of people (in many ROS-based companies, and the OSRF) are working to improve the situation. That doesn’t help me this week. Now, why are the DevOps people here so conservative? Because doing a remote update on a robot in the field, and having it fail, has two impacts: 1) we stop billing the customer until the robot is running again, and 2) we put someone on an airplane to make the robot run again. > > I'm tempted to launch into a diatribe about namespacing, containers, and > application isolation generally, but before I do - why is it that you want to > use the system Python environment? Had you just not considered the option of > virtual environments? Legitimate questions. Fitting into the existing deployment flow, and ummm… can I wrap a venv in a .deb? ‘Cuz that would be cool. Another poster mentioned Anaconda…. I’m not a huge fan. I am using it extensively as part of the Udacity self-driving car class, and I will admit that it would be nearly impossible for Udacity to deploy the project environment any other way. But I see Anaconda as a very heavy-weight solution for projects requiring a huge infrastructure, and my problem is no where near large enough that the benefits justifies the cost. A simple venv is more in line. > > -glyph > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
