Remove dynamodb-local.

[woodruffw]

Upstream has stopped providing versioned URLs, and this package
is not open source.

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

Closes #9065.

[ilovezfs]

438 installs in the last month, but if it's closed source and unversioned, there's not much we can do here to rehabilitate it.

[rjcoelho]

Can we at least move it to https://github.com/Homebrew/homebrew-boneyard ?

[woodruffw]

There's no practical way to boneyard it, since it isn't versioned.

If you still need this package, I'd suggest moving it into a personal tap (and turning it into a head spec).

[rjcoelho]

Unversioned formulas is what boneyard is is used for, at least according to Homebrew/head-only which is now deprecated.

"This tap was deprecated because unversioned formulae provide a terrible UX. All formulae have been migrated to Homebrew/homebrew-core or the boneyard."

[woodruffw]

Right, I forgot that head-only had been merged into boneyard. My bad. There's still the issue of it being closed source, which may also exclude it from the boneyard (pinging @ilovezfs for an opinion on that).

I still think this would be better suited to a personal tap - boneyarded formulae don't receive updates at all (to either their url or their install process) and will inevitably break as a result. Keeping it in your own tap will allow you to update the formula as the package changes.

[MikeMcQuaid]

There's still the issue of it being closed source, which may also exclude it from the boneyard (pinging @ilovezfs for an opinion on that).

It does, yes. We shouldn't have closed source stuff in the Homebrew organisation at all any more. Similarly, the boneyard may die in future so adding things there is at our discretion.

[jancona]

As a user, just an FYI that removing things like this makes Homebrew significantly less useful to me.

[ilovezfs]

@jancona that is fair. However, it's outside the scope of the Homebrew organization for two independent reasons:

1. it's not versioned
2. it's not open source

We'd be happy to bring it back if those can both be addressed.

If getting it open-sourced is out of the question, I suspect getting it versioned is not, given that it used to be until recently. If you can get it versioned, but not open-sourced, then this could go in a PR to Homebrew Cask CC @vitorgalvao

See https://github.com/caskroom/homebrew-cask/blob/master/doc/cask_language_reference/stanzas/binary.md

[vitorgalvao]

the boneyard may die

Thinking of that sentence out of context makes me laugh! Looks like heavy metal lyrics.

As a user, just an FYI that removing things like this makes Homebrew significantly less useful to me.

I occasionally find this argument. Every time my answer is “consider a tap”. Taps are by far my favourite feature of HB. Deciding which formulae/casks can be accepted where and under which conditions is never-ending work and no doubt not all rules will appeal to everyone. But taps set you free from those rules. Taps are so easy to make and powerful, even the official repos are themselves taps. Removal of formulae/casks might make it less convenient for you, but HB(C) is just as powerful and useful with or without the core repos.

If you can get it versioned, but not open-sourced, then this could go in a PR to Homebrew Cask CC @vitorgalvao

See https://github.com/caskroom/homebrew-cask/blob/master/doc/cask_language_reference/stanzas/binary.md

Nothing to add. We’d very much consider a PR for this, yes.

[ilovezfs]

@vitorgalvao is there a Cask policy regarding things that are "unversioned" since they now use https://s3-us-west-2.amazonaws.com/dynamodb-local/dynamodb_local_latest.tar.gz ?

[vitorgalvao]

@ilovezfs The cask will just use version :latest and sha256 :no_check (example).

We prefer them to be versioned when possible, though.

[ilovezfs]

@vitorgalvao thanks!

[rjcoelho]

For ref I moved it to https://github.com/rjcoelho/homebrew-boneyard/blob/master/Formula/dynamodb-local.rb

[jancona]

@rjcoelho Thanks--you beat me to it! BTW, I tried using version :latest and sha256 :no_check as mentioned in @vitorgalvao's comment, but I got an error: version ':latest' should be a string.

[ilovezfs]

@rjcoelho that's cask syntax. You need to create a cask file. See https://github.com/caskroom/homebrew-cask/blob/master/doc/cask_language_reference/stanzas/binary.md and more generally the docs at https://github.com/caskroom/homebrew-cask

[hugodes]

I found the "brew services restart dynamodb-local" command to be really usefull, anyway I can keep this functionality now ?

[ilovezfs]

@hugodes I don't think we have cask + brew services integration yet, but brew services should work fine if you add the old formula to your own tap: https://github.com/Homebrew/brew/blob/master/docs/How-to-Create-and-Maintain-a-Tap.md#how-to-create-and-maintain-a-tap

[MikeMcQuaid]

As a user, just an FYI that removing things like this makes Homebrew significantly less useful to me.

@jancona As a maintainer, just an FYI that comments like this make Homebrew significantly less enjoyable for me and, as the lead maintainer doing the vast majority of my Homebrew work in my free time: that's a problem.

We don't make changes like this for no reason: Homebrew is under resourced and changes like this make it possible for us to continue to maintain Homebrew.

[jancona]

@MikeMcQuaid I appreciate the work you and the other maintainers do and I'm sorry my comment made you feel that way. That was not my intent. I tried to be careful in my wording. I didn't yell or demand satisfaction, I was simply trying to provide a datapoint.

Consider the situation from a user's viewpoint. I spent 10 minutes trying to figure out how to install a package that I had installed successfully on another machine a week ago. After trying various things, I landed on this issue which says the package has been deleted and can't be part of even the boneyard because it's not open source.

From my perspective, a package manager that isn't comprehensive is much less useful, because I then have to worry about multiple ways to install packages, not to mention possible conflicts between the different mechanisms. I understand that resources are limited and and you have to make choices, but my intent in commenting was not to make you feel bad, but to provide information about how your policies impact your users.

BTW, thanks to the folks in this thread who pitched in after my comment to get a solution. Perhaps in the future when you delete a package you could include a pointer to the alternatives brought up in this thread.

[MikeMcQuaid]

@jancona Thanks, I appreciate the apology.