Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

2018-02-22 Thread David Collier-Brown 
On Thursday, February 22, 2018 at 6:43:07 AM UTC-5, alex@gmail.com 
wrote:
>
> Yup, the package I'm working on really cannot have 2 instances even in 
> different import paths as it deals with a shared resource and code that 
> must be run on the main thread.
> So I have to choose between daisy chaining v1 to v2 to v3 etc.. or have a 
> central v0 where all the v1, v2, etc.. packages import.
>
> Daisy chaining would mean I would only have to code API translations for 
> the latest API but then it's debug hell and if one version in the chain 
> breaks, 
> it means fixing all the newer versions. Also there's a performance hit 
> going through many translations.
>

If I understand you correctly, v2's foo() has to call v1's foo() in the 
daisy-chain case.   This was one of the two common cases in Multics (and 
Solaris, and Linux glibc).  The other case was v1's foo() calling a wrapper 
around v2's foo().

We called these "updaters" and "downdaters", and implemented them in the 
same library, under the covers.

Feel free to drop me a line if you are interested, and see 
also 
https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/
 
fore some of the background.

--dave
dav...@spamcop.net

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

2018-02-22 Thread 'Axel Wagner' via golang-nuts 
On Thu, Feb 22, 2018 at 10:27 PM  wrote:

> On Thursday, February 22, 2018 at 9:53:20 PM UTC+8, Axel Wagner wrote:
>>
>> Daisy chaining would mean I would only have to code API translations for
>>> the latest API but then it's debug hell and if one version in the chain
>>> breaks,
>>> it means fixing all the newer versions. Also there's a performance hit
>>> going through many translations.
>>>
>>
>> I don't believe so. There's may be an increase in compile time though.
>>
>
> I was thinking of cases where the behavior is so different it needed to
> emulate old behavior so over time all the emulation adds up and would be
> more complex than just emulating based on v0/latest.
>
>
>> The real question though, is how other package management semantics would
>> solve this better. Is this actually accidental complexity or just
>> systematic complexity caused by "I need to both break compatibility *and*
>> have different versions coexist *and* still share Singleton state between
>> them?
>>
>
> The vgo blogs talk about coexistence of multiple versions so was just
> figuring out if it makes sense and how would that look like.
> I just like to be prepared for worst case scenarios, so stuff I was
> worried about may or may not actually happen. But better be safe than sorry.
>

Sure, I'm just saying that if you start with how you'd do this in a more
familiar packaging scheme, you might be able to transfer it to vgo - I'm
not convinced vgo makes this at all harder, it's simply a hard problem to
begin with.


> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

2018-02-22 Thread alex . rou . sg 
On Thursday, February 22, 2018 at 9:53:20 PM UTC+8, Axel Wagner wrote:
>
> Daisy chaining would mean I would only have to code API translations for 
>> the latest API but then it's debug hell and if one version in the chain 
>> breaks, 
>> it means fixing all the newer versions. Also there's a performance hit 
>> going through many translations.
>>
>
> I don't believe so. There's may be an increase in compile time though.
>

I was thinking of cases where the behavior is so different it needed to 
emulate old behavior so over time all the emulation adds up and would be 
more complex than just emulating based on v0/latest.
 

> The real question though, is how other package management semantics would 
> solve this better. Is this actually accidental complexity or just 
> systematic complexity caused by "I need to both break compatibility *and* 
> have different versions coexist *and* still share Singleton state between 
> them?
>

The vgo blogs talk about coexistence of multiple versions so was just 
figuring out if it makes sense and how would that look like.
I just like to be prepared for worst case scenarios, so stuff I was worried 
about may or may not actually happen. But better be safe than sorry.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

2018-02-22 Thread 'Axel Wagner' via golang-nuts 
On Thu, Feb 22, 2018, 12:43  wrote:

> On Thursday, February 22, 2018 at 5:29:23 PM UTC+8, Axel Wagner wrote:
>>
>> Have you read https://research.swtch.com/vgo-import? It talks about
>> singletons and also how to solve that with different import paths.
>> Note, that this is also independent of *how* the different import paths
>> are represented and distributed; for singletons it only matters what import
>> paths the compiler sees, whether they are committed physical directories or
>> whether the vgo tool automatically resolves them.
>>
>
> Yup, the package I'm working on really cannot have 2 instances even in
> different import paths as it deals with a shared resource and code that
> must be run on the main thread.
> So I have to choose between daisy chaining v1 to v2 to v3 etc.. or have a
> central v0 where all the v1, v2, etc.. packages import.
>

Both seem fine.

Daisy chaining would mean I would only have to code API translations for
> the latest API but then it's debug hell and if one version in the chain
> breaks,
> it means fixing all the newer versions. Also there's a performance hit
> going through many translations.
>

I don't believe so. There's may be an increase in compile time though.

Note also, that you don't have to Daisy-Chain down - AIUI you can daisy
chain up too. i.e. v1/singleton aliases into v2/singleton, aliases into
v3/singleton... That way any cost would only be paid by people on stale
versions. Yes, if vN breaks, that would also break vM for M work when there's a breaking change as then I'll have to update all
> versions.
>
Also it means that all version packages have to be from the same release or
> it breaks.
>
> If I just have one module at the root, is it right to assume all sub
> packages would be of the same commit and that there will be only one
> version of the module?
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

2018-02-22 Thread alex . rou . sg 
On Thursday, February 22, 2018 at 5:29:23 PM UTC+8, Axel Wagner wrote:
>
> Have you read https://research.swtch.com/vgo-import? It talks about 
> singletons and also how to solve that with different import paths.
> Note, that this is also independent of *how* the different import paths 
> are represented and distributed; for singletons it only matters what import 
> paths the compiler sees, whether they are committed physical directories or 
> whether the vgo tool automatically resolves them.
>

Yup, the package I'm working on really cannot have 2 instances even in 
different import paths as it deals with a shared resource and code that 
must be run on the main thread.
So I have to choose between daisy chaining v1 to v2 to v3 etc.. or have a 
central v0 where all the v1, v2, etc.. packages import.

Daisy chaining would mean I would only have to code API translations for 
the latest API but then it's debug hell and if one version in the chain 
breaks, 
it means fixing all the newer versions. Also there's a performance hit 
going through many translations.

Having a v0 means non of all the daisy chaining problems but it means more 
work when there's a breaking change as then I'll have to update all 
versions.
Also it means that all version packages have to be from the same release or 
it breaks. 

If I just have one module at the root, is it right to assume all sub 
packages would be of the same commit and that there will be only one 
version of the module?

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

2018-02-22 Thread 'Axel Wagner' via golang-nuts 
On Thu, Feb 22, 2018 at 7:18 AM  wrote:

> I don't think changing the module name would be a good idea for singletons
> tho.
>

Have you read https://research.swtch.com/vgo-import? It talks about
singletons and also how to solve that with different import paths.
Note, that this is also independent of *how* the different import paths are
represented and distributed; for singletons it only matters what import
paths the compiler sees, whether they are committed physical directories or
whether the vgo tool automatically resolves them.


> And having a v0 has the added benefit of using newer codes while
> maintaining backwards compatible API.
> So no more backporting and all the mess of having multiple branches.
>

If you don't want multiple branches, you can commit your
version-directories and keep the same module name for all of them. If you
prefer having a single directory and different branches for different
version, you can have the version in the module line instead.

To the compiler, both are equivalent, the tool will resolve them to the
same thing.


>
> On Thursday, February 22, 2018 at 1:49:53 PM UTC+8, Sam Whited wrote:
>>
>> On Wed, Feb 21, 2018, at 22:35, alex@gmail.com wrote:
>> > vgo suggested that package developers put the major version into the
>> import
>> > path e.g. foo/v1.
>> > However dealing with a VCS like git, this thought occur to me, what
>> would
>> > it look like when the project needs to move from v1 to v2?
>>
>> This wasn't clear to me either, but it was pointed out that you can just
>> change the "module" line in your go.mod file, eg.
>>
>> module "example.net/mypackage/v2"
>>
>> and you don't have to actually create a /v2 tree or move your code around
>> at all.
>>
>> —Sam
>>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

2018-02-21 Thread alex . rou . sg 
I don't think changing the module name would be a good idea for singletons 
tho. 
And having a v0 has the added benefit of using newer codes while 
maintaining backwards compatible API.
So no more backporting and all the mess of having multiple branches.

On Thursday, February 22, 2018 at 1:49:53 PM UTC+8, Sam Whited wrote:
>
> On Wed, Feb 21, 2018, at 22:35, alex@gmail.com  wrote: 
> > vgo suggested that package developers put the major version into the 
> import 
> > path e.g. foo/v1. 
> > However dealing with a VCS like git, this thought occur to me, what 
> would 
> > it look like when the project needs to move from v1 to v2? 
>
> This wasn't clear to me either, but it was pointed out that you can just 
> change the "module" line in your go.mod file, eg. 
>
> module "example.net/mypackage/v2" 
>
> and you don't have to actually create a /v2 tree or move your code around 
> at all. 
>
> —Sam 
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

2018-02-21 Thread Sam Whited 
On Wed, Feb 21, 2018, at 22:35, alex.rou...@gmail.com wrote:
> vgo suggested that package developers put the major version into the import 
> path e.g. foo/v1. 
> However dealing with a VCS like git, this thought occur to me, what would 
> it look like when the project needs to move from v1 to v2?

This wasn't clear to me either, but it was pointed out that you can just change 
the "module" line in your go.mod file, eg.

module "example.net/mypackage/v2"

and you don't have to actually create a /v2 tree or move your code around at 
all.

—Sam

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.