Deploying a C# app through pip
“If we bundle up this C# application inside of a Python package archive we can deploy it through our internal CheeseShop server with very little work.”
That sentence got me a lot of WTF’s and resulted in one of the worst abuses of any system I’ve ever committed.
We had a C# service that would run locally and provide an HTTP REST API for huge amounts of data in our database that was difficult to work with.* However, we had no good way to deploy a C# application, but we needed to get this out to users so people could start building tools against it.
I refused to deploy it by running it out of source control. That is how we used to do stuff and it caused endless problems. I also refused bottlenecks like IT deploying new versions through Software Center.
So in an afternoon, I wrote up a Python package for building the C# app, packaging it into a source distribution, and uploading to our Cheese Shop. The package also had functions for starting the packaged C# executable from the installed distribution. The package then became a requirement like anything else and was added to a requirements.txt
file that was installed via pip.
What I initially thought was an unsightly hack ended up being perfect for our needs. In fact it caused us to eliminate a number of excessive future plans we had around distribution. I certainly wouldn’t recommend this “technique” for anything more than early internal distribution, but that’s what we needed and that’s what it did so effectively.
Getting something up and running early was extremely useful. It’s important to walk the line between the “we need to do several weeks of work before you see any result” and “I can hack something together we’re going to regret later,” especially for infrastructure and platform work. If code is well-written, tested, documented, and explained, you shouldn’t have qualms about it going into (internal) production. If the hackiness is hidden from clients, it can be easily removed when the time comes.
* Reworking the data was not an option. Creating this service would have allowed us to eventually rework the data, by providing an abstraction, though.
An alternate solution to consider when needing to package non-python software in a mostly Python ecosystem is conda: http://conda.pydata.org/
I take this is some flavor of *nix so you couldn’t just do ClickOnce?
We could have probably gotten away with ClickOnce since Linux wasn’t on the immediate roadmap. However a) none of us had used it and I didn’t want to spend the time learning it, and b) I wasn’t even sure it fit our requirements, for example some code branches would need different versions of our service. So immediately our use case was already quite advanced.
This scenario is why conda exists.
While conda seems great, changing deployment or other code to install and use conda is exactly the type of thing I was trying to avoid.
I don’t think this “technique” is too unreasonable, especially given that you used your own Cheese Shop.
[…] provide an HTTP REST API for huge amounts of data in our database that was difficult to work with.* However, we had no good way to deploy a C# application, but we needed to get this out to users so […]