+1 on avoiding side effects from business logic. This applies not just to Toucan, but to database code in general. Toucan is there to give you a way to define behaviors when interacting with your application database, for example transforming certain columns when you fetch rows from a certain table from the database. It's that plus utility functions for interacting with your database. Not really an ORM.
Either way, Toucan 2 is out now: https://github.com/camsaul/toucan2 I'm still working on fully documenting it but it's already being used in the wild and Toucan 1 will probably be archived soon
This library started out as DB and model layer utility functions for Metabase (https://github.com/metabase/metabase), and after a couple years of improving them we think they might be useful to others too, so we've spun them out into a separate library :)
I love how it was said that something like this has "only happened 3 times in the last 2 years". The fact that it's so easy to break npm is hilarious, and of course the maintainers don't care.
This feels very wrong to me. I know, open source, etc., and it's likely that the source license allows it provided the license remain intact, but still... For better or worse (worse, IMHO), the author decided to un-publish his nam modules. He asserted his authority over that package of his code. For npm to usurp his authority, even if the licensing allows it, feels wrong.
By choosing to publish his work as open source, he made it possible for npm to do this. One of the great things about open source licenses if that the original author decides to remove their work (regardless of whether on valid grounds or not), the community can still access it.
If he wanted the ability to prevent who is able to reuse and distributed his code, a proprietary license would have been a more suitable choice.
Nope, nothing wrong. The code he wrote is his, but he doesn't own the npm namespace, which is all anyone cares about here at this point.
But you know what also _feels_ wrong? people who had no involvement in this at all having their day get fucked up because of this one dude who _suddenly_, just now realized that npm isn't going to really help him out and did the internet equivalent of taking your ball and going home.
Agreed, that feels wrong too. But is npm supposed to be the recess supervisor in this metaphor, taking the ball back and giving it back to the other kids?
The particular license chosen for this module doesn't put any limitations on the code - the 'do whatever the fuck you want' license is as permissive as it gets. If the author doesn't like that, he might want to choose a less permissive license next time around.
Did they? Most open source licenses aren't revokable - you don't have to stop distributing the code just because the author asks you to stop. That seems especially true in this case, considering the author chose[1] to license left-pad under the WTFPL[2]. I'd say re-publishing the package counts as NPM doing "whatever the f* they want" with the code.
You can't retroactively change license. Sure, the author could push a new version with a new license, but the old versions would still be governed by the old license.
Yeah, I appreciate that, but if this becomes a general concern that npm can grant ownership to whoever it deems acceptable (even to the point of republishing existing versions), then could we start seeing e.g. WTFPL with npm exceptions style licence fragmentation.
The source could still be readily available to anyone to republish as they see fit, but only as a different name / version.
Not condoning it, just thinking that the original author surely has the right to do this if they plan ahead (judging by the npm backlash that has been building over a single entity holding all the keys some may be starting to think this way).
All open source licenses allow the licensee to republish your code - that's part of the definition. It's not going to trigger license fragmentation because any exceptions will make it not open source.
If you want to enforce that other people use different names for their forks, the usual way to do this is with trademarks - this is what e.g. mozilla and redhat do. Npm should respect your trademarks, and if someone else publishes a project under your trademarked name you can make npm take it down... which is exactly what originally happened here.
If you delete a module, the name becomes free. Someone else grabbed it and publishing code he has a license to redistribute under it. NPM is "only" fudging with the version number, the author gave the module away.
I can't agree. The author licensed the code under WTFPL, meaning he directly authorized anyone to do whatever with it in pretty much the most explicit and unambiguous terms possible.
Writing a 15 line function shouldn't grant someone the right to break an entire language ecosystem
I think the real issue though here is technical - does npm really allow mutation of published assets like this? That's a shitty situation that can only lead to unreliable builds
Pray tell, what is the minimum size that should be required before permitting a dependency? Constant-time string compare is only 5 lines or so, should we cutpaste security critical functions too? "We ran your code on $new_arch and discovered a timing attack." "It's not my fault!@# The professionally maintained and reviewed implementation was too small to depend on!@#!"
> First, you should never have a dependency for 15 lines.
If those 15 lines are called throughout your codebase, you should do what? Re-write the 15 lines and stuff them into a lib that you maintain? And everyone else should do this, too?
If a library is widely useful, it's widely useful regardless of how many LOC it contains.
Yes. With dependency you are giving up control and in return you save time in not having to implement the dependency. If the LoC is small you get practically nothing in return and so the only reason to do it is ideological.
Many times it is even faster to write a trivial "module" yourself than even discover it on npm, let alone reading and verifying it. Hell, NPM 3.x is so slow that it's literally faster to write any 1 liner "module" than it is just to install it.
"Reuse" is just a means to an end, it doesn't make sense to do it only for its own sake.
