package docopts

[Sylvain303]

provide a debian package for docopts.

Other package will be added. Ask for it or contribute.

We need:

• man page
• other package requisites
• tag a release

[agilgur5]

Other than Debian / apt-get and Homebrew (#59), some other package managers may be appropriate or easier to set-up as well.

For instance, on Windows:

• Chocolatey
• Scoop, probably in the extras bucket as docopts currently isn't popular enough to be considered for main.

On Linux, these are more for full apps than simple binaries, but provide a cross-distro package manager too:

• Snapcraft
• (also Flathub, but it does not have a great experience for CLIs)
• (and AppImageHub, which is a bit more complex than snap, IMO)

Others:

• asdf version manager

Homebrew is the main one for macOS, already covered by #59, but it also supports Linux and WSL nowadays.

Thought I'd document a few here. I might work on some of these so this lib can be easier to install on other OSes!

[Sylvain303]

Hello,

I though, while you were introducing brew tap stuff and goreleaser, that goreleaser tool won't probably make what I call a valid debian package.

Not just a .deb. file that install a binary and some other stuff somewhere in the OS. I was meaning a full real package following debian's maintainer rules to be eligible to be introduced in debian official repository.

It follows my philosophy of doing thing well. Discussed elsewhere. (I will edit visually later the Issue's description to keep the collected discussion and resolution to some top sticky location, aka the description)

Unfortunately last 10 years of development tend to provide out-distro distribution way. Like releases in github, and pre-built binary or add-apt-repository from random location, evil curl-pipe-sudo-bash, etc.

Even if the release comes from the official developer main's repository. Because it doesn't guaranty the fact the package follow the long time crafted OS rules... Nor of being reviewed for not breaking stuff on the OS, neither introduce malicious code. Could be intentionally from the developer, or through the build process.

There was hijacking history in free software hosting website...

That was what the OS guaranteed packaging system was offering. Official package are trusted and validated through some process. May be the process is dissuasive. May be for good reason...

Let's try to pass #65 first, for the github release purpose. Then it should permit #59 for the brew tap stuff for mac OS. For the other distribution, as you stated goreleaser may offer free cool generator, too. But we will see at the moment a user will come asking for. This is actually too many open possibility for me to handle in parallel for docopts.

And the need never came before, as the target is bash and mostly Linux.
I'm glad to welcome support for macOS legacy bash 3.2 +brew upgrade to recent version, as it also matches working with any legacy system. And the fact that it experiments on statically built binary. Which may also bring dual opposite requirement for packaging.

We should probably avoid container / confined deployment workflow for performance issue. We are providing a fast parser to making cli. We won't introduce a >80Mb binary load and overhead starting time. It seems to me very counter intuitive and counter productive here. The test I made trying to introduce a distinct API based on JSON parsing were awful at just repetitive huge (>2Mb) docopts binary in repetitive single script call... I abandoned this development and I will cancel the branch and the related link in README. We moved for docopts.sh wrapper which is more efficient here.

[agilgur5]

I though, while you were introducing brew tap stuff and goreleaser, that goreleaser tool won't probably make what I call a valid debian package.

Not just a .deb. file that install a binary and some other stuff somewhere in the OS. I was meaning a full real package following debian's maintainer rules to be eligible to be introduced in debian official repository.

Yeaaaa.... I realized that later too. goreleaser can automate third-party distribution, but not first-party (or at least not currently -- I might think about contributing that to goreleaser 🤔 )

Unfortunately last 10 years of development tend to provide out-distro distribution way. Like releases in github, and pre-built binary or add-apt-repository from random location, evil curl-pipe-sudo-bash, etc.

That was what the OS guaranteed packaging system was offering. Official package are trusted and validated through some process. May be the process is dissuasive. May be for good reason...

So there's good and bad things about that. Trade-offs.

On the one hand, out-of-distro distributions makes packages way more accessible in a variety of ways. So things that might have taken years to release in a distro can come out immediately instead.
docopts is potentially a good example too -- for some package managers/distros, it wouldn't be "popular enough" to even be considered. So one can only distribute out-of-distro in some cases. And some easily accessible form of distribution is necessary for a library to gain popularity and adoption.
That also means that small, independent devs can release libraries and don't need a major company backing them or whole team working on it to do so.

On the other hand, yea it's less "secure" in terms of there being less trust involved and required, and yea it may be less compatible with distros etc because it's not required to follow rules to be approved, and same for things like performance, size, etc.
Some big corporations have also opted-out of in-distro so that they're not "controlled" or bottlenecked by a different entity -- but that would have probably happened either way, those corporations are big enough to make their users do whatever.

I think there's more good then bad overall. Would be good if library developers had a "guide" of sorts where things can start as unofficial, third-party, out-of-distro distributions, and then slowly move to official, first-party, in-distro distribution as time allows.

There was hijacking history in free software hosting website...

Mmmmm most reports like these are a tad overblown. Because anyone can publish, yes, some of the libraries are going to be malicious, basically by definition.
The real question is, who's downloading these malicious packages? Generally the answer is almost no one. They're not popular, maintained, time-old, or trusted libraries, so the average developer isn't going to be downloading it.
So the impact isn't quite so bad as these "eye-catching" headlines would suggest.

But we will see at the moment a user will come asking for. This is actually too many open possibility for me to handle in parallel for docopts.

Yea understood on that front -- can treat me as a "distribution maintainer" of sorts so I'll handle most of the work for distributing things if I take these tasks on.
Once the Go modules stuff is complete (to allow for simple, standardized builds), most of the distribution portions happen in a different repo anyway, like inside of Homebrew/homebrew-core or inside of ScoopInstaller/Extras.
Per #59, some package managers, like Homebrew, actually require that the person creating the distribution is not the same as the library maintainer.

So what would be left to do in this repo is just add a note in the README of how to install from various package managers.

So hopefully you can see from that perspective, it shouldn't put much work on you at all. And that's my intention -- to do it myself, not require you to do more work.

And the need never came before, as the target is bash and mostly Linux.

There's a bit of a chicken-and-egg problem here though. Less people use this library because it's not available on various package managers. So I'm hoping more people and companies will use it once it's on Homebrew etc and more easily accessible.

The test I made trying to introduce a distinct API based on JSON parsing were awful at just repetitive huge (>2Mb) docopts binary in repetitive single script call... I abandoned this development and I will cancel the branch and the related link in README. We moved for docopts.sh wrapper which is more efficient here.

Yea I read about this. Didn't know size was the major issue. I thought performance was the main issue.

We should probably avoid container / confined deployment workflow for performance issue. We are providing a fast parser to making cli. We won't introduce a >80Mb binary load and overhead starting time. It seems to me very counter intuitive and counter productive here.

Agreed, would want to avoid that. Some of these methods don't introduce a huge overhead like that though. I'll do some testing on my end though when I get to this to double-check sizing etc!