Earlier quoted context omitted.
They're running a business. They offer an inordinate amount of service totally free to millions of developers, and they make their actual client open-source for your pleasure. Is your argument they also have to go to the trouble of making their infrastructure easily self-hosted? How would they make the money to pay the lawyers to respond to the very legal threat this tweet is about without revenue?
Please, it's arbitrary to run a private PyPi repository, all you need is a web server and a certain folder structure. If you want, you can even host everything on a private S3 and use a tiny Nginx configuration to authenticate the requests on behalf of pip [1]. Private npm repositories are an entirely different beast, and like GP mentions, there is no great option here. [1] https://www.guido.nyc/pypi-s3/
Major bank accidentally published a private package to the public NPM Registry
191–200 of 236 posts
Re: Major bank accidentally published a private package to the public NPM Registry
#192Re: Major bank accidentally published a private package to the public NPM Registry
#193A recent experience tells me this is a very easy mistake to do, though. I was using Yarn to publish a package to an internal package repository (so setting `private: true` was not an option). I did not know at the time that Yarn would not honor `publishConfig` in the `package.json` file, and it would also ignore the package's organisation set in `.yarnrc` (which is used to direct read operations to the internal repos…
(Public) Orgs _are_ free on NPM (at least nowdays) so maybe even that wouldn't have saved you.
Re: Major bank accidentally published a private package to the public NPM Registry
#194Earlier quoted context omitted.
At some points in a language and its package management system's lifetime, reducing barriers to publishing are one of the best things that can be done to increase packages and fill out the ecosystem, and drive utility and adoption. Later, once you have most needs filled by packages, and a good number of enterprise users, more control is beneficial. Companies appreciate it, and single users are willing to jump through…
This is going to be cynical, but as far as I understand it people are looking for usability through vanity. Why not install `com.facebook.react’? Reverse domain notation is remarkably elegant given our internet. You are not typing ‘npm i com.facebook.react’ so often that it’s a pain. You probably use ‘create-react-app’ which is even worse. Instead, every language creates a new cash grab for common names. And made it…
That would be a bad idea, and it's not just brevity.
- If com.facebook.hr has previously been published, would it mean that facebook can never have a division named HR?
- Once a company goes belly up, the domain often ends up with squatters/spammers. Domains with published packages will sell for a lot more in the underground market - for pure exploitation of rights to publish a newer version.
- In the absence of validation, nothing stops anyone from publishing com.google.exploitlib. And domain validation is friction.
- Most publishers on npm may not have a domain.
And finally like someone mentioned below, npm already supports scoped packages. https://docs.npmjs.com/about-scopes
Re: Major bank accidentally published a private package to the public NPM Registry
#195A recent experience tells me this is a very easy mistake to do, though. I was using Yarn to publish a package to an internal package repository (so setting `private: true` was not an option). I did not know at the time that Yarn would not honor `publishConfig` in the `package.json` file, and it would also ignore the package's organisation set in `.yarnrc` (which is used to direct read operations to the internal repos…
> What saved me was that the package was inside an organisation ("@foo/bar") and those are not free on NPM... (Public) Orgs _are_ free on NPM (at least nowdays) so maybe even that wouldn't have saved you.
Re: Major bank accidentally published a private package to the public NPM Registry
#196Re: Major bank accidentally published a private package to the public NPM Registry
#197Slightly off topic, but my experience with lawyers and technology has been mostly discouraging. For example, one lawyer wanted to sue a client of ours for using an open-source JS dropdown menu that we were also using--he said they stole our code. He was also concerned that we were letting people 'View Source' our web pages and stealing our IP.
Re: Major bank accidentally published a private package to the public NPM Registry
#198Re: Major bank accidentally published a private package to the public NPM Registry
#199Earlier quoted context omitted.
> If their code is proprietary, no one can use it. Even if they accidentally uploaded it to a public site. Surely this depends on the terms under which they uploaded it. I would expect npm to have a legal structure in place under which code you upload for public use is also licensed for public use.
> I would expect npm to have a legal structure in place under which code you upload for public use is also licensed for public use. Not how it works. For example, see the license field here: https://www.npmjs.com/package/unlicensed
NPM doesn't appear to have a "default license" though, so that would be "no license", therefore normal copyright law would seem to apply, and you can't make a copy of it, and more than you can copy a picture on a billboard or a blog post or whatever.
Re: Major bank accidentally published a private package to the public NPM Registry
#200A recent experience tells me this is a very easy mistake to do, though. I was using Yarn to publish a package to an internal package repository (so setting `private: true` was not an option). I did not know at the time that Yarn would not honor `publishConfig` in the `package.json` file, and it would also ignore the package's organisation set in `.yarnrc` (which is used to direct read operations to the internal repos…