121–130 of 137 posts
Earlier quoted context omitted.
Which won't stop it happening with a package manager either. Even immutable repos are going to have fun with DMCAs.
npm hosted the packages so acted like a cache, the same didn’t happen when people deleted repos
Earlier quoted context omitted.
Customers ability to 1. Punish innovation and 2. Punish a lack of innovation is a little bit hard to overestimate as a Product Manager. Experimentation = bad, no experimentation = also bad. It's like how Google makes some of the best software ever, and also people savagely denounce them every time they kill a failing product. As if they would have learned as fast if they either didn't make the product to begin with o…
It isn't a customer's responsibility to be a company's guinea pig, and it's not a secret that customers would be unhappy that tech companies treat them as such. This is especially true when Product Managers intentionally implement features that take advantage of users by monetizing their data and then implementing high switching costs that make it even more painful for the customer once the Product Manager ends their…
Earlier quoted context omitted.
This is not unique to Go, every language I work with can use dependencies in this way.
How about java projects? How can I add a dependency to a project I’m building without it being published to a maven repo, for instance?
You can use Gradle, which supports source repositories, instead of Maven:
Earlier quoted context omitted.
I think a tool like that could be very useful! The main issue with basing it off of Git commits is that there is no guarantee that the last commit with a given version is actually a good version. Consider the case where a-1.0 depends on b-1.0 and b is updated to b-2.0 in a commit so that a is not compatible with b-2.0. Even though a-1.0 is still around, it's not going to work until we update it to a-2.0, so you need…
Wouldn’t it be enough to checkout the commit where a-x.0 was updated, rather than the last known commit where a is at x.0? That way, if the packagr built successfully at that commit, you know it’s a good version. We do something similar (and the way more manual) here[0]. [0]: https://github.com/dapphub/dapptools/blob/master/overlay.nix...
Earlier quoted context omitted.
npm hosted the packages so acted like a cache, the same didn’t happen when people deleted repos
What happened when the npm owner decided to remove some packages? Why would you trust one npm owner than the package author? Can't you just cache the package if you need cache?
They can’t, at least not older packages, I believe they need to contact NPM if they wish to unpublish packages. https://docs.npmjs.com/cli/unpublish
Earlier quoted context omitted.
You know what'd be really cool? For either Nix or Guix to transparently support installation of any version of any program without hacks like putting an alternate version under a different name or some such. I wish programs didn't require continued maintenance for dependency updates or risk being uninstallable without putting them and a number of dependencies under different package names. I wish I could install Fire…
> I wish I could install Firefox or Chrome from a decade ago as easily as I can install the latest versions. You can, on Windows. The secret is the system keeping backwards compatibility in mind for its core APIs, something that most desktop APIs on Unix (outside of X11) do not do.
Earlier quoted context omitted.
> I wish I could install Firefox or Chrome from a decade ago as easily as I can install the latest versions. You can, on Windows. The secret is the system keeping backwards compatibility in mind for its core APIs, something that most desktop APIs on Unix (outside of X11) do not do.
The main problem in Linux is dependency updates, and I never understood how dependencies in Windows work. Are most programs built as fat binaries that carry all their dependencies with them? Or do Windows programs just never build on top of other 3rd party programs and always just depend on what's provided by the base OS?
(now the asterisk: in terms of functionality above and taking an average desktop distribution in mind you'd probably find more of it in Linux, but applications can't rely on most of that functionality being available on all distros as a "standard" and even for the stuff they could expect, way more often than not they rely on specific version ranges - e.g. an application cannot rely on "Gtk", it can only rely on "Gtk .xxx", as Gtk itself isn't backwards compatible across major versions).
Earlier quoted context omitted.
Honestly, I think I like doing it with git more. If you maintain such a "database", you'd have to explicitly state version info for the dependencies of every package. That's done automatically with git. For a particular version of a package, the versions of the dependencies it's compatible with are those that are present in the same commits. Also, to maintain package building scripts in a database outside of git woul…
The default way to consume nixpkgs is through channels which today does not involve git. And a nixpkgs git checkout is over 1GB (my .git dir is currently sitting at 1.4GB on this machine). So that's not great. > If you maintain such a "database", you'd have to explicitly state version info for the dependencies of every package. I don't know what you mean. If I say "I want git v2.10.0" I don't care about dependencies;…
EDIT:
> The default way to consume nixpkgs is through channels which today does not involve git. And a nixpkgs git checkout is over 1GB (my .git dir is currently sitting at 1.4GB on this machine). So that's not great.
One could also add tags to the repo in the form of pname-version for every package. I wonder how well git can handle that many tags...
In any case, the advantage of being able to do this from the git repo is that you wouldn't depend on someone forever hosting every version of a channel. I would think one would discard old channels before they discard git history.
> is a software package hosting service, similar to npmjs.org, rubygems.org, or hub.docker.com, that allows you to host your packages and code in one place. You can host software packages privately or publicly and use them as dependencies in your projects. I am... really confused by this. Isn't this just Github? Github is a hosting service that allows you to host your packages and code in one place. It has testing an…
> what can I do now that I couldn't already do with Github as is? Before this new service how would you use GitHub as a source for installing, for example, Maven packages?
http://www.lordofthejars.com/2011/09/questa-di-marinella-e-l...
For all the features GitHub has, this is the only one that myself and those that I know personally have made us care and watch very closely what GitHub does with this. We've been looking for a simple way to streamline releases. Right now everything we have at my job is on GitLab and I use GitLab personally (though I have a github account, of course). I prefer GitLab in every way, but this feature alone might be a goo…
At GitLab, the CE edition currently offers a container registry, that allows users to build, push and share images using the Docker client and/or GitLab CI/CD.
The EE edition offers an NPM and Maven registry, that allows users to publish, download and share dependencies. Both also integrate with GitLab CI/CD. We are currently working on Conan (C/C++) and NuGet (.NET). We are evaluating moving these features to CE as well.
We also offer a proxy to for Docker images (which will be extended to each registry) that improves reliability and performance and (in the future) will help mitigate and remediate open source risk.
If you end up trying GitHub's registry, I'd love to hear more about what you thought.