7 ms·

StableLib – Stable Distribution of Go Packages

48 points by joshrotenberg 12y ago

sagichmal 12y ago
I'm confused, is this a curated set of existing Go libraries, or a brand-new set of libraries? If the former, how are they going to guarantee their "3 years of bug fixes"? If the latter, why should I trust them to produce higher-quality code than the community has already?
- nknighthb 12y ago
  > I'm confused, is this a curated set of existing Go libraries, or a brand-new set of libraries? Toward the bottom of the page they talk about contributing back to open source projects and sponsoring the development of some packages, so it certainly appears to be a curated set of existing Go libraries. > If the former, how are they going to guarantee their "3 years of bug fixes"? Red Hat provides 10+ years on the code they ship. What's so shocking about 3?
  - sagichmal 12y ago
    > Red Hat provides 10+ years on the code they ship. What's so shocking about 3? Does Red Hat ship (and maintain) arbitrary 3rd party code?
    - dchest 12y ago
      Most of their code is third-party code.
    - nknighthb 12y ago
      All Linux distributions consist primarily of third-party code. I don't know what you mean by "arbitrary", though. It makes no sense in context, and is notably at odds with your earlier use of the word "curated". Nobody ships random code. That wouldn't be curated, nor would it be useful.
0xdeadbeefbabe 12y ago
I still worry that devs who say, "oh crap we can't build because of this library" are doing something wrong. I'm curious why I must depend on complexities like this or godeps to write effective go either by myself or in a team. Can't you just take a snapshot of the source including third party libs and keep it somewhere safe? Edit: stablelibs is an inviting idea if you believe you must vendor, and plenty of people do believe that.
- Zikes 12y ago
  I think vendoring is being officially promoted, with a concrete workflow/plan in the works to be announced later.
  - dchest 12y ago
    Yes, here's a post by bradfitz https://groups.google.com/d/msg/golang-dev/nMWoEAG55v8/iJGgur7W_SEJ https://groups.google.com/d/msg/golang-dev/nMWoEAG55v8/iJGgu...
- dchest 12y ago
  Can't you just take a snapshot of the source including third party libs and keep it somewhere safe? That's what vendoring is for — freezing your dependency on some version. What StableLib provides is a guarantee that the API of package remains stable, but also that all the latest major/security bugs are always fixed (by backporting them). Also, that you're always notified about any critical/security fixes. Of course, you can also do vendoring with StableLib-provided packages, and we plan to make it easy via the command-line tool.
ffk 12y ago
Does anyone have any info on who is behind this? I can't find any details.
- dchest 12y ago
  I'm behind this :-) I've been using Go since its public release (I think I wrote the first public Go project — https://news.ycombinator.com/item?id=938046 https://news.ycombinator.com/item?id=938046 :-). I also contributed to Go, mostly /x/crypto stuff such as scrypt and salsa, and wrote lots of open source packages — https://github.com/dchest https://github.com/dchest. StableLib is an effort to help businesses use third-party Go packages without worry.
  - ffk 12y ago
    Fantastic, can you mention this on your page? :)
    - dchest 12y ago
      Yes, will do. It definitely needs a FAQ and more information about the team.
dchest 12y ago
Hi, StableLib is my project. Happy to answer your questions!
- dougbarrett 12y ago
  Is the purpose of this project just to guarantee that bug fixes will be supported with projects? For example, I use martini, negroni, gorm and mgo on a daily basis. If I switch to your repos, is it that there are no concerns that the repo will ever disappear, or if there are critical bugs you will help fix them if the project developer disappears? I think the issue I can't get my head wrapped around is, at what point does your service become relevant? What happens if one of the libraries updates something in the original repo or adds a new feature, is that a dot release for you?
  - dchest 12y ago
    > What happens if one of the libraries updates something in the original repo or adds a new feature, is that a dot release for you? Details about versioning are still in development, but here's the rough idea: If it's a small reviewable feature that can be applied without breaking anything, then yes, it will probably go into a dot release of the package. For example, you use "github.com/dchest/siphash" package. In StableLib it's version v1.0.0 (vX.Y.Z), available via "stablelib.com/v1/crypto/siphash". Notice v1 in import path — this is the major version of the whole StableLib release (X). All version within v1.Y.Z are guaranteed to have the same API, so you can upgrade v1.0.0 to v1.0.1 or v1.1.0 and your application won't break. Now, if dchest/siphash fixes a bug, it will be releases as v1.0.1 in StableLib. If it introduces a new feature, which doesn't break API, say, additional function to calculate 128-bit hash, it will be v1.1.0 in StableLib. In general, you will be on the latest release within the major StableLib release. Sometime in the far feature we will release StableLib v2, which will break API, and will be available at stablelib.com/v2/..., so your v1 packages will still work. I'm happy to hear any suggestions.
    - dougbarrett 12y ago
      Got it, and for the other part? I'm just wondering what makes this entirely different from github assuming that the authors don't remove the project or delete their account. I think I'm just unclear on what value you are adding and for current projects why I would use your repositories over the actually package developer. I'm genuinely interested in this as a service, as I have ran into issues where packaged have API breaking changes that I'm not aware of until we pull code on the production server when we're ready to launch, but I'm just not sure if I'm clear on the intentions.
NateDad 12y ago
I have three main concerns - one is that the original package authors get credit... Right now it looks like you're obscuring that by totally replacing the original import path with your own (leaving out the github username). Second is that I worry that bugs won't get filled against the original repos for people using your version. Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with. And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault.
- nknighthb 12y ago
  Your concerns apply equally to software aggregations generally -- e.g. every Linux distribution. Import paths are not the appropriate method of providing "credit". That's the sort of thing that is handled by copyright notices, documentation, and metadata. It's generally preferred that if you're using a software distribution, you either test bugs against a "pure" upstream version before reporting them, or report them to the maintainers of the distribution, who can triage and, when appropriate, forward bug reports upstream (possibly with patches).
- dchest 12y ago
  I have three main concerns - one is that the original package authors get credit... Right now it looks like you're obscuring that by totally replacing the original import path with your own (leaving out the github username). They get credit in README (the upstream path is there), on the website description of package, and, of course, their LICENSE, AUTHORS, CONTRIBUTORS files are all there. We do not want to take any credit from them. Second is that I worry that bugs won't get filled against the original repos for people using your version. We'll do it for them! When a StableLib subscriber reports a bug to us, after confirming it, we will file the bug upstream (possibly even a pull request fixing it), and: a) if the bug is critical or security related, and the patch is available — it gets applied to StableLib immediately, b) if the bug is minor or we couldn't figure out how to fix it ourselves, we wait until the upstream fixes it, and backport the fix to our version. In fact, we will recommend ourselves as the first point of contact in case of a bug instead of upstream, and do all the upstream bug reporting/relations ourselves. This way upstream package authors won't be bothered if the bug report is invalid, or if the bug doesn't apply to their version. Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with. I'd prefer to keep the package as close to the original as possible — it's in our best interest, as merges/backports are easier if it's so. In any debate, the author always wins (if their view won't damage security of package). And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault. That's why StableLib subscribers would first report bug to us. Thank you for your great points! This will help us with creating a FAQ.
damian2000 12y ago
The website isn't rendering properly for me .. lettering is borked across all fonts - sort of when a bitmap has been resized without using anti-aliasing. Using Firefox 37.0.1 on Win7.
- dchest 12y ago
  Thank you, I will check with this configuration. Edit: should be fixed now.
wilsonfiifi 12y ago
The first thing that came to mind was that this is similar to ActiveState's PyPm [0] for Python but it seems this might be offering a bit more by way of bug fixes etc... All in all seems like a great product/idea! [0] http://www.activestate.com/activepython/pypm-python-modules
- dchest 12y ago
  Thank you! I new about ActiveState, but didn't know about PyPm.

48 points by joshrotenberg 12y ago

I'm confused, is this a curated set of existing Go libraries, or a brand-new set of libraries? If the former, how are they going to guarantee their "3 years of bug fixes"? If the latter, why should I trust them to produce higher-quality code than the community has already?

nknighthb 12y ago
> I'm confused, is this a curated set of existing Go libraries, or a brand-new set of libraries? Toward the bottom of the page they talk about contributing back to open source projects and sponsoring the development of some packages, so it certainly appears to be a curated set of existing Go libraries. > If the former, how are they going to guarantee their "3 years of bug fixes"? Red Hat provides 10+ years on the code they ship. What's so shocking about 3?
- sagichmal 12y ago
  > Red Hat provides 10+ years on the code they ship. What's so shocking about 3? Does Red Hat ship (and maintain) arbitrary 3rd party code?
  - dchest 12y ago
    Most of their code is third-party code.
  - nknighthb 12y ago
    All Linux distributions consist primarily of third-party code. I don't know what you mean by "arbitrary", though. It makes no sense in context, and is notably at odds with your earlier use of the word "curated". Nobody ships random code. That wouldn't be curated, nor would it be useful.

0xdeadbeefbabe 12y ago

I still worry that devs who say, "oh crap we can't build because of this library" are doing something wrong. I'm curious why I must depend on complexities like this or godeps to write effective go either by myself or in a team. Can't you just take a snapshot of the source including third party libs and keep it somewhere safe? Edit: stablelibs is an inviting idea if you believe you must vendor, and plenty of people do believe that.

Zikes 12y ago
I think vendoring is being officially promoted, with a concrete workflow/plan in the works to be announced later.
- dchest 12y ago
  Yes, here's a post by bradfitz https://groups.google.com/d/msg/golang-dev/nMWoEAG55v8/iJGgur7W_SEJ https://groups.google.com/d/msg/golang-dev/nMWoEAG55v8/iJGgu...
dchest 12y ago
Can't you just take a snapshot of the source including third party libs and keep it somewhere safe? That's what vendoring is for — freezing your dependency on some version. What StableLib provides is a guarantee that the API of package remains stable, but also that all the latest major/security bugs are always fixed (by backporting them). Also, that you're always notified about any critical/security fixes. Of course, you can also do vendoring with StableLib-provided packages, and we plan to make it easy via the command-line tool.

ffk 12y ago

Does anyone have any info on who is behind this? I can't find any details.

dchest 12y ago
I'm behind this :-) I've been using Go since its public release (I think I wrote the first public Go project — https://news.ycombinator.com/item?id=938046 https://news.ycombinator.com/item?id=938046 :-). I also contributed to Go, mostly /x/crypto stuff such as scrypt and salsa, and wrote lots of open source packages — https://github.com/dchest https://github.com/dchest. StableLib is an effort to help businesses use third-party Go packages without worry.
- ffk 12y ago
  Fantastic, can you mention this on your page? :)
  - dchest 12y ago
    Yes, will do. It definitely needs a FAQ and more information about the team.

dchest 12y ago

Hi, StableLib is my project. Happy to answer your questions!

dougbarrett 12y ago
Is the purpose of this project just to guarantee that bug fixes will be supported with projects? For example, I use martini, negroni, gorm and mgo on a daily basis. If I switch to your repos, is it that there are no concerns that the repo will ever disappear, or if there are critical bugs you will help fix them if the project developer disappears? I think the issue I can't get my head wrapped around is, at what point does your service become relevant? What happens if one of the libraries updates something in the original repo or adds a new feature, is that a dot release for you?
- dchest 12y ago
  > What happens if one of the libraries updates something in the original repo or adds a new feature, is that a dot release for you? Details about versioning are still in development, but here's the rough idea: If it's a small reviewable feature that can be applied without breaking anything, then yes, it will probably go into a dot release of the package. For example, you use "github.com/dchest/siphash" package. In StableLib it's version v1.0.0 (vX.Y.Z), available via "stablelib.com/v1/crypto/siphash". Notice v1 in import path — this is the major version of the whole StableLib release (X). All version within v1.Y.Z are guaranteed to have the same API, so you can upgrade v1.0.0 to v1.0.1 or v1.1.0 and your application won't break. Now, if dchest/siphash fixes a bug, it will be releases as v1.0.1 in StableLib. If it introduces a new feature, which doesn't break API, say, additional function to calculate 128-bit hash, it will be v1.1.0 in StableLib. In general, you will be on the latest release within the major StableLib release. Sometime in the far feature we will release StableLib v2, which will break API, and will be available at stablelib.com/v2/..., so your v1 packages will still work. I'm happy to hear any suggestions.
  - dougbarrett 12y ago
    Got it, and for the other part? I'm just wondering what makes this entirely different from github assuming that the authors don't remove the project or delete their account. I think I'm just unclear on what value you are adding and for current projects why I would use your repositories over the actually package developer. I'm genuinely interested in this as a service, as I have ran into issues where packaged have API breaking changes that I'm not aware of until we pull code on the production server when we're ready to launch, but I'm just not sure if I'm clear on the intentions.

NateDad 12y ago

I have three main concerns - one is that the original package authors get credit... Right now it looks like you're obscuring that by totally replacing the original import path with your own (leaving out the github username). Second is that I worry that bugs won't get filled against the original repos for people using your version. Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with. And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault.

nknighthb 12y ago
Your concerns apply equally to software aggregations generally -- e.g. every Linux distribution. Import paths are not the appropriate method of providing "credit". That's the sort of thing that is handled by copyright notices, documentation, and metadata. It's generally preferred that if you're using a software distribution, you either test bugs against a "pure" upstream version before reporting them, or report them to the maintainers of the distribution, who can triage and, when appropriate, forward bug reports upstream (possibly with patches).
dchest 12y ago
I have three main concerns - one is that the original package authors get credit... Right now it looks like you're obscuring that by totally replacing the original import path with your own (leaving out the github username). They get credit in README (the upstream path is there), on the website description of package, and, of course, their LICENSE, AUTHORS, CONTRIBUTORS files are all there. We do not want to take any credit from them. Second is that I worry that bugs won't get filled against the original repos for people using your version. We'll do it for them! When a StableLib subscriber reports a bug to us, after confirming it, we will file the bug upstream (possibly even a pull request fixing it), and: a) if the bug is critical or security related, and the patch is available — it gets applied to StableLib immediately, b) if the bug is minor or we couldn't figure out how to fix it ourselves, we wait until the upstream fixes it, and backport the fix to our version. In fact, we will recommend ourselves as the first point of contact in case of a bug instead of upstream, and do all the upstream bug reporting/relations ourselves. This way upstream package authors won't be bothered if the bug report is invalid, or if the bug doesn't apply to their version. Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with. I'd prefer to keep the package as close to the original as possible — it's in our best interest, as merges/backports are easier if it's so. In any debate, the author always wins (if their view won't damage security of package). And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault. That's why StableLib subscribers would first report bug to us. Thank you for your great points! This will help us with creating a FAQ.

damian2000 12y ago

The website isn't rendering properly for me .. lettering is borked across all fonts - sort of when a bitmap has been resized without using anti-aliasing. Using Firefox 37.0.1 on Win7.

dchest 12y ago
Thank you, I will check with this configuration. Edit: should be fixed now.

wilsonfiifi 12y ago

The first thing that came to mind was that this is similar to ActiveState's PyPm [0] for Python but it seems this might be offering a bit more by way of bug fixes etc... All in all seems like a great product/idea! [0] http://www.activestate.com/activepython/pypm-python-modules

dchest 12y ago
Thank you! I new about ActiveState, but didn't know about PyPm.