Golang libraries distribution - Binary packages vs Source

[swami nathan]

Hi Gophers,

I have been working with Golang for quite sometime. I'm writing libraries using it. 

Now, I'm planning to take this product to next level and I might go commercial through my organisation, which I'm currently working on.

I need your suggestions on distributing these libraries when going commercial.

There are two options I have in table now,

1. Providing the source code of the library directly and allowing the customers to build in their environment.

2. Providing the precompiled binary packages for different platforms without exposing the source.

AFAIK, providing the precompiled binary packages is not compatible with different versions of Go (even minor version). For instance, if the binary packages are compiled with 1.4, it can be only used with 1.4 in customer environment. Correct me, if I'm wrong.

So my questions are,

1. For commercial purpose, what are the options and the best option for distributing the libraries?

2. Is Go fraternity requires to provide the sources by default? So, that customer could build it in any platforms and Go versions.

3. If there is a possibility for providing binary packages, let me know whether I have to provide build (release) for each versions of Go release?

I'm not an expert in Go. This is my understanding. 

Please enlighten with your thoughts, so it would help me in my proposal with my company.

Thanks in advance!

Note: Providing the sources might be a problem with my organization. 

--

​​

Regards,

Swaminathan M

[Egon]

On Thursday, 1 January 2015 17:42:29 UTC+2, Swaminathan M wrote:

Hi Gophers,

I have been working with Golang for quite sometime. I'm writing libraries using it. 

Now, I'm planning to take this product to next level and I might go commercial through my organisation, which I'm currently working on.

I need your suggestions on distributing these libraries when going commercial.

There are two options I have in table now,

1. Providing the source code of the library directly and allowing the customers to build in their environment.

2. Providing the precompiled binary packages for different platforms without exposing the source.

AFAIK, providing the precompiled binary packages is not compatible with different versions of Go (even minor version). For instance, if the binary packages are compiled with 1.4, it can be only used with 1.4 in customer environment. Correct me, if I'm wrong.

So my questions are,

1. For commercial purpose, what are the options and the best option for distributing the libraries?

As a library user, I would prefer source - it's easier to see what's happening, find problems inside the library, give feedback to the library maintainer, see how you are using the library wrong etc. The library source is sometimes very useful.

Obviously this would mean the code has to be complex to avoid people from simply rewriting the code. I.e. a reason why you would want to keep it private.

Some library companies simply provide two versions "compiled" and "source", where "source" version costs more.

 

2. Is Go fraternity requires to provide the sources by default? So, that customer could build it in any platforms and Go versions.

AFAIK it doesn't require.

 

3. If there is a possibility for providing binary packages, let me know whether I have to provide build (release) for each versions of Go release?

You can also setup a simple service for library users to build their "custom" version for some particular Go version. Sometimes the project needs a fix in the standard libraries or Go to make things work; although that is an edge case.

If you have the "compiled" and "source" model, then you can simply state that the "compiled" version is only provided for go stable/rc releases.

[minux]

On Thu, Jan 1, 2015 at 10:41 AM, swami nathan <swam...@gmail.com> wrote:

I have been working with Golang for quite sometime. I'm writing libraries using it. 

Now, I'm planning to take this product to next level and I might go commercial through my organisation, which I'm currently working on.

I need your suggestions on distributing these libraries when going commercial.

There are two options I have in table now,

1. Providing the source code of the library directly and allowing the customers to build in their environment.

2. Providing the precompiled binary packages for different platforms without exposing the source.

AFAIK, providing the precompiled binary packages is not compatible with different versions of Go (even minor version). For instance, if the binary packages are compiled with 1.4, it can be only used with 1.4 in customer environment. Correct me, if I'm wrong.

So my questions are,

1. For commercial purpose, what are the options and the best option for distributing the libraries?

2. Is Go fraternity requires to provide the sources by default? So, that customer could build it in any platforms and Go versions.

even minor releases of Go doesn't promise ABI stability, so I'm afraid if you go to the binary release route,

you will have to provide precompiled .a files for each platform and each Go version that you support. 

3. If there is a possibility for providing binary packages, let me know whether I have to provide build (release) for each versions of Go release?

It's possible. Just remember to provide a dummy source file with timestamp earlier than the .a files. 

In the dummy source file, just having the package statement suffices, and normally you want to provide

the documentation in that file too, so that godoc will work.

What you can do is:

Extract all the exported functions/types/methods,constants along with their prototype and documentation

(but without the actual implementation) into the dummy file, say doc.go, and release both the dummy doc.go

and its precompiled .a together to a customer. Make sure to have the timestamp of the .a file later than the

doc.go, so go build will not attempt to rebuild the package.

As an example, doc.go could look like this:

// package XXX is ....

package XXX

// X is ....

type X int

const (

    X1 X = iota // X1 is ..

    X2 // X2 is ...

)

// F does .....

func (*X) F() error

// F1 does ..., and returns ....

func F1() (int, error)

It's enough to make godoc work and provide essential documentation for your package, but it leaves out

all the implementation details. I don't know if there are existing tools for this, but it should be fairly easy

to do with go/{ast,parser,printer} packages.

[swami nathan]

Thanks Minux!

Actually, I'm planning to generate godoc from the source files during the build, and removing the sources alone after that.

Godoc will be bundled along with the product and also published online.

Will that suffice??

--

Regards,

Swaminathan M

[minux]

On Thu, Jan 1, 2015 at 10:30 PM, swami nathan <swam...@gmail.com> wrote:

Actually, I'm planning to generate godoc from the source files during the build, and removing the sources alone after that.

Godoc will be bundled along with the product and also published online.

Will that suffice??

As long as `godoc import/path` shows correct document for your package.

it doesn't matter how you generate doc.go (if the documentation is published

online, even a doc.go that only contains "package pkgname" will do).

but be aware of the timestamp problem. doc.go must have an older time

stamp than the package archive file (*.a)

[swami nathan]

On Fri, Jan 2, 2015 at 9:05 AM, minux <mi...@golang.org> wrote:

As long as `godoc import/path` shows correct document for your package.

it doesn't matter how you generate doc.go (if the documentation is published

online, even a doc.go that only contains "package pkgname" will do).

but be aware of the timestamp problem. doc.go must have an older time

stamp than the package archive file (*.a)

​Yes, ​I have noted down that. Will take care of that timestamp problem :)

 

--

Regards,

Swaminathan M

[swami nathan]

On Thu, Jan 1, 2015 at 9:48 PM, Egon <egon...@gmail.com> wrote:

Some library companies simply provide two versions "compiled" and "source", where "source" version costs more.

​

Providing both the compiled and source versions seems to be a good option!​

 

You can also setup a simple service for library users to build their "custom" version for some particular Go version. Sometimes the project needs a fix in the standard libraries or Go to make things work; although that is an edge case.

If you have the "compiled" and "source" model, then you can simply state that the "compiled" version is only provided for go stable/rc releases.

​Yes, I would suggest for setting up the service for allowing the customers to build their custom version.

But if only ready-made builds are possible​

​/allowed by my company, whether updating the site with latest build (for each go stable/rc release) and maintaining a clone of previous, say 5 builds is a good idea??

We have provided products/libraries in Java earlier, wherein we just provide the JARS in universal way (as it is backward compatible, we don't have any issues there). 

So I'm just thinking, if the same way can be achieved when we do Go libraries??

As I'm completely new, I'm just trying to understand the Go way of doing things :)

 

​P.S.: I'm a budding developer, when I make this proposal to my company, I should provide alternate solutions/suggestions, when the option of providing source is ruled out (bcos of my company policies). :)​

--

Regards,

Swaminathan M

[swami nathan]

Egon,
Could you help me with the above questions??
Thank in advance!

[Egon]

On Friday, 2 January 2015 06:00:33 UTC+2, Swaminathan M wrote:

On Thu, Jan 1, 2015 at 9:48 PM, Egon <egon...@gmail.com> wrote:

Some library companies simply provide two versions "compiled" and "source", where "source" version costs more.

​

Providing both the compiled and source versions seems to be a good option!​

 

You can also setup a simple service for library users to build their "custom" version for some particular Go version. Sometimes the project needs a fix in the standard libraries or Go to make things work; although that is an edge case.

If you have the "compiled" and "source" model, then you can simply state that the "compiled" version is only provided for go stable/rc releases.

​Yes, I would suggest for setting up the service for allowing the customers to build their custom version.

But if only ready-made builds are possible​

​/allowed by my company, whether updating the site with latest build (for each go stable/rc release) and maintaining a clone of previous, say 5 builds is a good idea??

Basically, write some script/service that builds automatically and uploads them somewhere. It shouldn't be more than a days work to get something trivial up and running.

[Ian Lance Taylor]

On Thu, Jan 1, 2015 at 7:41 AM, swami nathan <swam...@gmail.com> wrote:
>
> I have been working with Golang for quite sometime. I'm writing libraries
> using it.
> Now, I'm planning to take this product to next level and I might go
> commercial through my organisation, which I'm currently working on.
>
> I need your suggestions on distributing these libraries when going
> commercial.
>
> There are two options I have in table now,
> 1. Providing the source code of the library directly and allowing the
> customers to build in their environment.
> 2. Providing the precompiled binary packages for different platforms without
> exposing the source.
>
> AFAIK, providing the precompiled binary packages is not compatible with
> different versions of Go (even minor version). For instance, if the binary
> packages are compiled with 1.4, it can be only used with 1.4 in customer
> environment. Correct me, if I'm wrong.
>
> So my questions are,
> 1. For commercial purpose, what are the options and the best option for
> distributing the libraries?
> 2. Is Go fraternity requires to provide the sources by default? So, that
> customer could build it in any platforms and Go versions.
> 3. If there is a possibility for providing binary packages, let me know
> whether I have to provide build (release) for each versions of Go release?

My experience, having been both a library vendor and customer, is that
the reasons that commercial library vendors have for withholding
source are rarely well thought out. You are going to sign some sort
of contract with your customers, and that contract is going to
prohibit them from redistributing your library. That contract can
apply to the source code just as well as the binaries. Your customers
are not your competitors; if they were, they would not be buying from
you. They are not going to steal your source any more than they are
going to steal your binaries.

So just give your customers your source code. That will make them
happier anyhow.

Ian

[Micah Nordland]

Hey all,
I've got a strange date format that I need parse: 02/JAN/06 03:04p.m.
That's the reference date expressed in it. time.Parse doesn't handle the
caps month name or pm separated by periods. Would patches be accepted
for those or should I just parse these myself?
--
Micah Nordland <mi...@rehack.com>
Public Key: http://www.thoughtfuldragon.com/public.key

[Rui Ueyama]

I don't think that needs to be supported as a built-in date format. You can convert a string into a format that can be read by time.Parse and then use time.Parse, can't you? It seems to me that you could lowercase the string and replace "p.m." to "pm" (and "a.m." to "am").

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Harden]

For parsing, you can use "02/Jan/06 03:04pm" and the matching for the month will be case insensitive. No such luck for p.m. though.

t, err := time.Parse("02/Jan/06 03:04pm", string.Replace(s, ".", "", -1))

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.