5 ms·

So a couple of things. First off, this is using AWS for two important services. That is probably a no go for a whole bunch of people right away. But where it r

So a couple of things. First off, this is using AWS for two important services. That is probably a no go for a whole bunch of people right away. But where it really lost me is that it is "yet another thing with a custom installer" or YATWACI (tm). Let me say it again: if you want wide adoption of your software, get it $@&!ing packaged for popular OS's. It is not hard, and is way nicer than "well first, create a virtualenv..."

dfc 10y ago
I doubt wide adoption of a tool used internally is at the top of the Netflix devs priority list. It solves an internal need and it does not hurt to throw some code over the wall, so why not toss it on github and see if you can get some free labor.
voltagex_ 10y ago
https://github.com/Netflix/bless/blob/master/Makefile https://github.com/Netflix/bless/blob/master/Makefile shows that it's pretty standard Python stuff, just wrapped up in a Makefile for ease of use. Packaging Python apps really really sucks - at least for Debian there's stdeb - https://pypi.python.org/pypi/stdeb/0.8.5 https://pypi.python.org/pypi/stdeb/0.8.5. No idea if it's lintian-clean though.
- alanfranzoni 10y ago
  Packaging almost anything sucks. Use fpm. Https://github.com/alanfranz/fpm-within-docker for native packages.
  - Bombthecat 10y ago
    No, use npm. Thats the hot sauce now :)
  - dozzie 10y ago
    FPM-created packages suck. They often have incorrect metadata format, most of the time they don't have any dependencies encoded, they often have crappily written initscripts (less of a problem today, with systemd everywhere) and similar infrastructural things. All that while writing RPM specs and proper(ish) debianization are quite easy.
    - bbrazil 10y ago
      > (less of a problem today, with systemd everywhere) Systemd is far from everywhere. Ubuntu 14.04 doesn't use it and is supported until 2019. Debian Wheezy is supported until 2018. RHEL 6 has support through to 2021. Overall this means it'll start to be reasonable to presume systemd sometime around 2020, and be realistically almost everywhere from say 2025. Software changes take 5-10 years to roll out everywhere. This is such a core change that it'll be on the longer side.
      - dozzie 10y ago
        Even though I agree with you here (I still use Wheezy, personally and professionally), most projects don't target that old releases, so they build mainly for modern mainstream (Debian/Ubuntu and Red Hat/CentOS), which means systemd. And that still doesn't change the fact that most programmers produce shitty packages, if any, so every time I use somebody's software I need to package it myself to have it properly built.
        voltagex_ 10y ago
        If the packaging files are in Git(Hub), raise an issue. A packaging bug is still a bug.
        dozzie 10y ago
        And for each and every package/project I would need convince the maintainer that he doesn't understand what he's doing, he's doing it wrong, and he should learn a correct method? Because it all boils to this (barring a more polite way of stating the fact).
brbsix 10y ago
Getting something correctly packaged for popular OS's is not as easy as it may seem. Even Torvalds famously gripes about it. Luckily, there's no need for that here since it can be distributed as a Python package. The project already uses setuptools (in setup.py) so it's most of the way there.
- digi_owl 10y ago
  The biggest problem with that is CADT among the toolkit lib devs, that in combination with rigid dependencies in distro package managers leads sprawling permutations.

dfc 10y ago

I doubt wide adoption of a tool used internally is at the top of the Netflix devs priority list. It solves an internal need and it does not hurt to throw some code over the wall, so why not toss it on github and see if you can get some free labor.

voltagex_ 10y ago

https://github.com/Netflix/bless/blob/master/Makefile https://github.com/Netflix/bless/blob/master/Makefile shows that it's pretty standard Python stuff, just wrapped up in a Makefile for ease of use. Packaging Python apps really really sucks - at least for Debian there's stdeb - https://pypi.python.org/pypi/stdeb/0.8.5 https://pypi.python.org/pypi/stdeb/0.8.5. No idea if it's lintian-clean though.

alanfranzoni 10y ago
Packaging almost anything sucks. Use fpm. Https://github.com/alanfranz/fpm-within-docker for native packages.
- Bombthecat 10y ago
  No, use npm. Thats the hot sauce now :)
- dozzie 10y ago
  FPM-created packages suck. They often have incorrect metadata format, most of the time they don't have any dependencies encoded, they often have crappily written initscripts (less of a problem today, with systemd everywhere) and similar infrastructural things. All that while writing RPM specs and proper(ish) debianization are quite easy.
  - bbrazil 10y ago
    > (less of a problem today, with systemd everywhere) Systemd is far from everywhere. Ubuntu 14.04 doesn't use it and is supported until 2019. Debian Wheezy is supported until 2018. RHEL 6 has support through to 2021. Overall this means it'll start to be reasonable to presume systemd sometime around 2020, and be realistically almost everywhere from say 2025. Software changes take 5-10 years to roll out everywhere. This is such a core change that it'll be on the longer side.
    - dozzie 10y ago
      Even though I agree with you here (I still use Wheezy, personally and professionally), most projects don't target that old releases, so they build mainly for modern mainstream (Debian/Ubuntu and Red Hat/CentOS), which means systemd. And that still doesn't change the fact that most programmers produce shitty packages, if any, so every time I use somebody's software I need to package it myself to have it properly built.
      - voltagex_ 10y ago
        If the packaging files are in Git(Hub), raise an issue. A packaging bug is still a bug.
        dozzie 10y ago
        And for each and every package/project I would need convince the maintainer that he doesn't understand what he's doing, he's doing it wrong, and he should learn a correct method? Because it all boils to this (barring a more polite way of stating the fact).

brbsix 10y ago

Getting something correctly packaged for popular OS's is not as easy as it may seem. Even Torvalds famously gripes about it. Luckily, there's no need for that here since it can be distributed as a Python package. The project already uses setuptools (in setup.py) so it's most of the way there.

digi_owl 10y ago
The biggest problem with that is CADT among the toolkit lib devs, that in combination with rigid dependencies in distro package managers leads sprawling permutations.