Introducing boiler, a plugin packaging and distribution system for unRAID

[ogi]

The situation above is dangerous and part of what boiler seeks to fix.

 

1. Centralized registry

 

No one is going to come to this thread to find a plg download linked to someone's dropbox that may or may not be around in days/months/years. A central registry provides an interface for reliably, trustworthy, versioned code.

 

2. Out of date packages

 

If the above package truly is an updated transmission, the appropriate action would be to send a Pull Request to Influencer with the updated code so that a common and recognized package is update more globally.

 

Boiler let's you get updates directly from the official plugin easily by running

 

boiler update NAME

 

2. Accountable developers

 

There are only a handleful of devs creating worthwhile packages. Boiler creates accountability for devs and gives them better tools to manage their code, including version control through git, issue management if you choose to use Github, and authorship credit defined in the package.

 

3. Safe and secure code

 

All source code is public and reviewable. If a malicious package is found, it can be easily stopped at the source. The exchange above is scary because it's just a random guys on an internet forum linking a distributable package from a personal, unverifiable source. The package above should be regarded as volatile: it could disappear at any time or even if it will be replaced by different code. There is no traceable history, no contact, and no accountability for upkeep.

 

4. Easy distribution

 

Boiler lets you search, install, and update packages so you can quickly install the packages you need and keep them up to date. Hunting through random threads on a forum is not an acceptable solution.

 

I don't disagree with any of the above; I would just like to know what I can do to help (as a non-developer). 

 

I wouldn't mind trying to transpose some of the packages into Boiler packages (someone above made Sabnzbd run with Boiler, no reason the same can't be done with SickBeard and so on); just might need to be given some google terms to query to get me started on the process.

[ars92]

The situation above is dangerous and part of what boiler seeks to fix.

 

1. Centralized registry

 

No one is going to come to this thread to find a plg download linked to someone's dropbox that may or may not be around in days/months/years. A central registry provides an interface for reliably, trustworthy, versioned code.

 

2. Out of date packages

 

If the above package truly is an updated transmission, the appropriate action would be to send a Pull Request to Influencer with the updated code so that a common and recognized package is update more globally.

 

Boiler let's you get updates directly from the official plugin easily by running

 

boiler update NAME

 

2. Accountable developers

 

There are only a handleful of devs creating worthwhile packages. Boiler creates accountability for devs and gives them better tools to manage their code, including version control through git, issue management if you choose to use Github, and authorship credit defined in the package.

 

3. Safe and secure code

 

All source code is public and reviewable. If a malicious package is found, it can be easily stopped at the source. The exchange above is scary because it's just a random guys on an internet forum linking a distributable package from a personal, unverifiable source. The package above should be regarded as volatile: it could disappear at any time or even if it will be replaced by different code. There is no traceable history, no contact, and no accountability for upkeep.

 

4. Easy distribution

 

Boiler lets you search, install, and update packages so you can quickly install the packages you need and keep them up to date. Hunting through random threads on a forum is not an acceptable solution.

 

Completely agree with what you've just said. But the only reason i linked my plg was that i wasnt on my pc, so i figured it was easier to just upload my plg rather than writing out the steps to get it up and running by himself.

 

A lot of new ideas are brewing in this forum now, i just hope the outcome spells the death of plugins and dependecy conflicts!

 

Sent from my SM-N9005 using Tapatalk

 

 

[nicinabox]

Totally, and you did nothing wrong per se. I wasn't trying to call you out in a mean way or anything. This is how it's been done for a while now, and I realize you were just trying to be helpful

[ironicbadger]

A lot of new ideas are brewing in this forum now, i just hope the outcome spells the death of plugins and dependecy conflicts!

 

Me too.

[ogi]

Totally, and you did nothing wrong per se. I wasn't trying to call you out in a mean way or anything. This is how it's been done for a while now, and I realize you were just trying to be helpful

 

I don't think we have any miss-communication here.  While I'm far from a linux guru, I think Boiler (or some other central package manager) is necessary, and I want to contribute to the project.

 

I suppose it's possible that my best way of contributing is financially; which is fine.  I just want to be able to help migrate unRAID in this direction in some constructive manner.

Ogi

[nicinabox]

Personally, I wish we could get away from the idea of "plugins". Modularity is key in any systems and being able to distribute reusable, independent code is not a new idea. "Plugin" sounds like some sort of half-assed, neutered package that someone created as a one-off and never looked back at it.

 

 

[nicinabox]

I suppose it's possible that my best way of contributing is financially; which is fine.  I just want to be able to help migrate unRAID in this direction in some constructive manner.

Ogi

 

Boiler needs packages to become a viable alternative, and that means devs need to create packages in this fashion. The current documentation is somewhat technical. Perhaps a how-to tutorial on creating a simple package would help lower the bar? Plus, you'd have a good understanding of how it works (it's pretty simple). The best way to learn is to teach!

[ogi]

I suppose it's possible that my best way of contributing is financially; which is fine.  I just want to be able to help migrate unRAID in this direction in some constructive manner.

Ogi

 

Boiler needs packages to become a viable alternative, and that means devs need to create packages in this fashion. The current documentation is somewhat technical. Perhaps a how-to tutorial on creating a simple package would help lower the bar? Plus, you'd have a good understanding of how it works (it's pretty simple). The best way to learn is to teach!

 

I was considering doing a simple package in boiler (like the screen package, maybe a SSH server).

 

I don't know what the ...standard practice(?) would be for trying to convert an existing plg plugin that someone else wrote into a boiler package... do you generally ask the developer for permission to do so? 

[nicinabox]

I suppose it's possible that my best way of contributing is financially; which is fine.  I just want to be able to help migrate unRAID in this direction in some constructive manner.

Ogi

 

Boiler needs packages to become a viable alternative, and that means devs need to create packages in this fashion. The current documentation is somewhat technical. Perhaps a how-to tutorial on creating a simple package would help lower the bar? Plus, you'd have a good understanding of how it works (it's pretty simple). The best way to learn is to teach!

 

I was considering doing a simple package in boiler (like the screen package, maybe a SSH server).

 

I don't know what the ...standard practice(?) would be for trying to convert an existing plg plugin that someone else wrote into a boiler package... do you generally ask the developer for permission to do so? 

 

Depends on the license. Some may not have a specified license, in which case normal copyright laws apply (nobody else may reproduce, distribute, or create derivative works). In that case it's probably best to contact the author to have them assign a license.

 

Otherwise, you're free to do as the license allows. I make most of my stuff MIT, which is extremely permissible.

 

When converting plgs there may be some parts that can be done better in boiler. Plg is a flat xml file and if you start to dig into them, you'll notice odd (but kind of necessary) practices that aren't needed in normal packages (an example of this is using /tmp to create files for the plugin, then copying them where they need to go. In a standard package, you'd just create the files to begin with). The converter in boiler may not work completely for all plgs because they have no real standards. You have to comb over the result and test it.

 

Another consideration is: what actually makes a good package? Here are some tips:

 

Try not to duplicate slackware-package functionality. Packages don't need to be re-wrapped, they can be installed directly with trolley. The exception to this is when you need to provide unraid-specific functionality. OpenSSH is a good example. Keys need to be persisted on reboot, so the standard installation needs to be tweaked a little. This would be a good candidate for a boiler package that requires openssh (from slackware) as a dependency.

 

You want to distribute other software for use with unraid. I'm working on a package right now that sets up tvnamer for unraid. It has an editable configuration, a cron job, and needs to persist across reboots. This kind of functionality is useful in a package.

 

Boiler has a growing set of APIs to abstract the crappy parts of package design and make it really easy for authors to specify complex functionality through a simple configuration.

[nicinabox]

0.3.0 is out with a number of improvements and new features

 

See https://github.com/nicinabox/boiler/releases/tag/0.3.0 for release.

 

Update your existing installation with:

 

boiler update boiler

 

or install fresh:

 

wget -qO- http://getboiler.com/install | sh -

 

Report issues on Github.

[bonienl]

Boiler has a growing set of APIs to abstract the crappy parts of package design and make it really easy for authors to specify complex functionality through a simple configuration.

 

Perhaps it is a good idea  to write a tutorial and show the possibilities, knowing is believing as the saying goes 

[nicinabox]

Boiler has a growing set of APIs to abstract the crappy parts of package design and make it really easy for authors to specify complex functionality through a simple configuration.

 

Perhaps it is a good idea  to write a tutorial and show the possibilities, knowing is believing as the saying goes 

 

This is true. It's all documented in the readme, but a simple how-to would go a long way I think

[nicinabox]

I've released a set of guides as per bonienl's suggestion. Covers everything from basic usage to creating and registering a new package.

 

Check it out here: http://getboiler.com/guides/

[bonienl]

I've released a set of guides as per bonienl's suggestion. Covers everything from basic usage to creating and registering a new package.

 

Check it out here: http://getboiler.com/guides/

 

A very nice write up, very helpful.

 

What about existing plugins (PLG files), anything needs to be changed or adapted to work with boiler ? If yes, an example of the modification steps could help plugin authors, just a thought.

 

Keep up the good work!

 

Ps. Any reason to go with Ruby instead of PHP (just out of interest, not intended as a start of a war flame for one or the other)

[nicinabox]

I've released a set of guides as per bonienl's suggestion. Covers everything from basic usage to creating and registering a new package.

 

Check it out here: http://getboiler.com/guides/

 

A very nice write up, very helpful.

 

What about existing plugins (PLG files), anything needs to be changed or adapted to work with boiler ? If yes, an example of the modification steps could help plugin authors, just a thought.

 

Keep up the good work!

 

Oh yeah, let me whip up a guide for that!

 

Ps. Any reason to go with Ruby instead of PHP (just out of interest, not intended as a start of a war flame for one or the other)

 

I've designed Boiler to be language agnostic in order to meet a wide range of needs. Personally, I think you'll find your applications better built in a language like Ruby or Python. They will be more maintainable and easier to read. I think you'll find this Ruby helpers file from Boxcar easier to understand than the equivalent PHP one from Limetech's webGui. Not to mention, Ruby has a fantastic testing framework--something that would go a long way to making folks' packages more reliable and bug free.

 

My opinion is that you should use a language with quality standards. PHP has the stigma of being a "beginner language", and as such, a lot of what you'll find is rather subpar (although this is not necessary a fault of the language itself).

[bonienl]

My opinion is that you should use a language with quality standards. PHP has the stigma of being a "beginner language", and as such, a lot of what you'll find is rather subpar (although this is not necessary a fault of the language itself).

 

PHP isn't that bad 

 

Both have their pros and cons, there all several nice comparisons written, but if you feel comfortable with Ruby then keep using it.

 

At the end of the day it is not the tools which determine the quality of the work, but the one using them !

[ogi]

I've released a set of guides as per bonienl's suggestion. Covers everything from basic usage to creating and registering a new package.

 

Check it out here: http://getboiler.com/guides/

 

That's great to see these.  I've just moved into a new apartment and am still in the process of unpacking.  One done I'll get started with these...

 

Ogi

[nicinabox]

I should also point out that these guides are available on Github. If you have a problem with something in the guides, feel free to make an issue about it, or send a pull request with the fix. There *could* be mistakes, although I tried to be very thorough with them.

[jbrodriguez]

i dont use plugins in unraid and i really don't like ruby, but ... it's an awesome work you did here nicinabox ! cheers !!!

[nicinabox]

i dont use plugins in unraid and i really don't like ruby, but ... it's an awesome work you did here nicinabox ! cheers !!!

 

Thanks, I appreciate that

 

At the end of the day, the tech stack really doesn't matter. What does matter is being able to ship really great, reliable, useful software to make people happier and their lives easier.

 

Ruby happens to be tool in my toolbox that I know well.

[nicinabox]

Update Jan 20

I have a draft of the Converting a PLG guide. 0.3.1 is really close, but needs additional testing before release. I'm probably a few days behind schedule on this.

 

---

 

Update:

 

I'm doing a major refactor of the codebase with rspec. Fixed a lot of bugs along the way and I feel a lot more confident about the reliability of the codebase. I also feel confident in accepting code contributions because the chance of someone breaking the build is much lower now. I'll be setting up a CI server this week to run the specs automatically.

 

If all of this is confusing to you, just know that I'm making boiler as reliable and robust as possible.

 

0.3.1 will be out by the end of the week with a new guide on converting plgs.

 

Cheers!

[Duppie]

Hi nicinabox

 

I like trolley quite a lot  . Thanks for this, but for 64bit it only looks at 14.0 as the latest. Should it not look at 14.1 slackware?

 

Thanks

 

Duppie

[nicinabox]

Hi nicinabox

 

I like trolley quite a lot  . Thanks for this, but for 64bit it only looks at 14.0 as the latest. Should it not look at 14.1 slackware?

 

Thanks

 

Duppie

 

It should, and the next release does. I'm finishing up some last touches on it, but I expect to have a new release for both boiler and trolley by the end of the weekend with 64 bit support.

[DaleWilliams]

... I expect to have a new release for both boiler and trolley by the end of the weekend with 64 bit support.

[me=DaleWilliams]twiddles thumbs as he awaits the newest Trolley!  [/me]

[nicinabox]

If anyone is available to help me with getting a 6.0 VM running I would be eternally grateful.

 

I have a 5.0.x VM (using VirtualBox) that works, but I can't seem to get it upgraded without errors. I wanted to create a new fresh virtual disk and machine for 6.0, but after several hours, I've made no progress.

 

This is the only thing blocking me from doing 64-bit testing for boiler and trolley.