Re: [go-nuts] Go += Package Versioning

[sam boyer]

Unfortunately, the rules also create some new perverse incentives, with 
some, IMO, nastier failure modes and remediations. That's one of the things 
i'll be elaborating on in my doc (hopefully) next week.

That said, one of the points Russ and i agree on is that dep does allow 
more expressiveness than is wise.

On Tuesday, February 20, 2018 at 1:55:59 PM UTC-5, David Anderson wrote:
>
> I love this. I want it now.
>
> I've struggled with `glide` and `dep` dependency hell a lot in my Go 
> projects (especially those that use the Kubernetes client library, which 
> abuses "I, the library author, can define byzantine constraints on my 
> users" to the extreme). The way I've described it informally is that 
> traditional "arbitrary version selection" algorithms create the wrong 
> incentive structure for library authors, in the sense that they have all 
> the power to lock versions arbitrarily, but bear none of the pain 
> associated with their decisions - instead, the binary author at the apex of 
> the dependency tree gets that pain. "Authority without responsibility" is 
> the death of many incentive structures.
>
> The proposed rules around semver and minimal version selection address 
> every pain point I've had so far, by aligning available authority with the 
> responsibility of the library authors: tell me what versions definitely 
> will *not* work, and I'll take it from there.
>
> Questions that arose during reading:
>
>- In the "defining Go modules" section, you say: "Although semantic 
>versions are strongly preferred, referring to specific commits will be 
>supported as well." Then, you specify that such commits order before 
>v0.0.0. To me, this suggests that this feature will be useless, because 
> any 
>non-trivial example will have *some* semver constraint somewhere in 
>the dependency tree, such that in practice commit-hash versions will 
> always 
>be overridden by minimal version selection. I don't have a solution to 
> this 
>(other than removing support for commit-hash versions), but it seems like 
>it's something to think about
>   - One alternative I considered, but discarded, was to order all 
>   tags and commits by their date, and run minimal version selection on 
> that. 
>   However, this doesn't work because semver tag dates don't grow 
>   monotonically - you might have 0.1.2 released after 0.2.0, which leads 
> to 
>   confusing behavior to the user - why did 0.2.0 get selected when 0.1.2 
> was 
>   a "better" minimal version?
>- Modules as zip archives: how do I discover which versions are 
>available? Minimal version selection seems to rely on being able to list 
>the version continuum for a module, so that constraints can be applied. 
>What's the expected way to do that?
>- Writing module files sounds like a job for a machine, in cases where 
>I don't care which version gets used. Can `goimports` (or a new sibling 
>tool) be taught to update module definitions based on my code?
>- No GOPATH required: YES! Thank you. I share Zellyn's question on 
>what happens to `go install` in this world. Does it go away? Does it 
>install to some new $GOBINARYINSTALL or somesuch?
>
> Haven't read the vgo tour yet, it may answer some of these. I may be back 
> with more :)
>
> - Dave
>
>
> On Tue, Feb 20, 2018 at 9:20 AM, Russ Cox  
> wrote:
>
>> Hi everyone,
>>
>> I have a new blog post you might be interested in.
>> https://research.swtch.com/vgo.
>>
>> I'll try to watch this thread to answer any questions.
>>
>> Best,
>> Russ
>>
>>
>>
>> -- 
>> 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.
>>
>
>

-- 
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] dep: Roadmap for merging into the toolchain

[Sam Boyer]

I'm don't think that's an accurate summary, at all.

On Tuesday, March 14, 2017 at 3:22:22 AM UTC-4, Jan Mercl wrote:
>
> On Tue, Mar 14, 2017 at 8:01 AM Konstantin Khomoutov <
> flat...@users.sourceforge.net > wrote:
>
> > Please don't miss the monumental heaps of discussions about package
> management in Go [1].
>
> Executive summary: Solving the Go's package dependency resolution problem 
> can be either automatic or correct. Pick one.
>
> -- 
>
> -j
>

-- 
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] dep: Roadmap for merging into the toolchain

[Sam Boyer]

Hi Russ -

thanks, this is great. I think all of this will be much easier with these 
discussions happening in the open.

On Monday, March 13, 2017 at 5:09:19 PM UTC-4, Russ Cox wrote:
>
> On Tue, Mar 7, 2017 at 6:47 AM, Sam Boyer <samuel@gmail.com 
> > wrote:
>
>> Hi folks,
>>
>> Since we opened up the dep project <https://github.com/golang/dep> in 
>> late January, there's been flurry of contributions, which has been great. 
>> However, the plans and end goal of dep haven't been entirely clear to 
>> everyone.
>>
>> To address that, and help guide contributors, we've put out a roadmap 
>> <https://github.com/golang/dep/wiki/Roadmap>.
>>
>> We're hoping to have dep ready to merge into the toolchain at the 
>> beginning of the 1.10 cycle. But that'll only happen if the community steps 
>> up even more to help!
>>
>
> Hi Sam,
>
> You make it sound like dep is just going to become 'go dep' in Go 1.10. 
> That's not the plan I thought we discussed.
>

Ahh, if that's the way it's coming across, I apologize! I've tried to 
adhere as closely to the plans we've discussed as possible. At times, in 
some places (particularly high-level docs like roadmaps), I've omitted some 
detail, in favor of making the project approachable for new contributors.

For example, I can see how the wording I used in the OP here could be read 
as suggesting that it would become `go dep` in 1.10, which would violate 
your subcommand complexity requirement. That wasn't my intent; I most 
recently reiterated that requirement earlier today 
<https://github.com/golang/dep/issues/168#issuecomment-286148978>.

My guess is that my general enthusiasm about all of this may be obscuring 
some of the uncertainty. I mean...I'm enthusiastic about this effort, what 
can I say :) More on this at the bottom.

 

>
> As I wrote to you and the package management group in January:
>
> I think it's very important instead to weave package and dependency 
> management into the go command so that you don't notice it as a separate 
> thing in day-to-day work. As a result, I see dep as an important 
> improvement over current practice that's usable immediately, an important 
> step toward a final solution, and also an experiment that helps us learn 
> more about what structure works for people, but I don't see it, for 
> example, as a prototype of the eventual go command integration (since it's 
> not integrated at all).
>
> In particular, I agree strongly with all of these decisions in dep:
>
> - Manifest file listing version requirements.
> - Lock file listing exact versions for a reproducible build.
> - Version control repo as project granularity is good.
> - Calling the group of packages released as a unit a "project" is a good 
> name to establish.
> - Implementing coordination with the build by populating vendor is clearly 
> the right implementation.
>
> For eventual integration with the go command and the broader go toolchain, 
> some of the decisions are likely not optimal. In particular:
>
> - go get vs not. Dep creates a parallel world separate from 'go get'. 
> Having two is not great. Ideally, I'd like 'go get' to improve instead of 
> adding a second mechanism.
> - Subcommand complexity. As mentioned in #25, if dep foo became 'go dep 
> foo', then it would be the first sub-sub-commands and likely indicates a 
> less than clean integration.
> - Vendor directories. As an implementation mechanism today, these make 
> sense. They stop making sense if we can change the toolchain. Instead of 
> translating the lock file into an ephemeral vendor directory, the tooling 
> can just read the lock file directly.
> - Multiple packages. At scale, I think allowing v1 and v2 of a single 
> package to be linked into the final binary is unavoidable. It's also not 
> possible to express in the "top-level vendor directory" model. Another 
> reason to eliminate the "translate lock file to vendor directory" step.
> - GOPATH vs not. As I understand it, dep continues to assume GOPATH, but 
> in a multiversion world that may not be appropriate. We need to understand 
> the implications here. GOPATH has to keep working well, but I think we 
> probably want 'git clone foo && cd foo && do work' outside GOPATH to work 
> equally well, and package management has an important role to work out here.
>
>
> I understand that not changing the go command was a constraint from the 
> discussions at Gophercon and also from the point of view of making 
> something people can use today. That's absolutely appropriate and correct 
> for dep. But for long-term integration, I think we do need to rethink these 
> aspects of the go command itself. 
>
&

[go-nuts] dep: Roadmap for merging into the toolchain

[Sam Boyer]

Hi folks,

Since we opened up the dep project  in late 
January, there's been flurry of contributions, which has been great. 
However, the plans and end goal of dep haven't been entirely clear to 
everyone.

To address that, and help guide contributors, we've put out a roadmap 
.

We're hoping to have dep ready to merge into the toolchain at the beginning 
of the 1.10 cycle. But that'll only happen if the community steps up even 
more to help!

cheers
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.

[go-nuts] [ANN] gta - test combinations of deps

[Sam Boyer]

hi folks,

i've just gotten a new project to a vaguely-working-alpha state (release 
early, release often!) that facilitates automatically testing combinations 
of possible dependency versions: https://github.com/sdboyer/gta. it's 
gps-based (https://github.com/sdboyer/gps), and is at least sorta 
cross-package-manager.

it's kinda like git bisect, but for your deps! feedback is very, very 
welcome.

kudos to spf13 for suggesting something like this in the first place.

cheers
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] tbsp - Spoon-feed your table-based tests!

[Sam Boyer]

Hmm, I hadn't thought about that. But doing that might actually make it 
worth using as a library. There are definitely a couple things I wouldn't 
be able to replicate, but I'll think about it.

In the meantime...PRs welcome :)

On Thursday, August 25, 2016 at 12:41:17 PM UTC-4, Nick Craig-Wood wrote:
>
> On 17/08/16 16:06, Sam Boyer wrote: 
> > OK, so this is kind of a lark, but to celebrate the new subtesting 
> > system <https://golang.org/pkg/testing/#hdr-Subtests_and_Sub_benchmarks> 
>
> > in Go 1.7, I fired out a quick lib for executing table-based 
> > tests https://github.com/sdboyer/tbsp. 
> > 
> > The implementation is pretty trivial, so I hardly expect people to 
> > actually import it. But, it's a nice little demonstration of what I 
> > think table-based testing should generally start to look like, now that 
> > subtests are a thing. 
> > 
> > Sorry if there's already something out there like this - I totally 
> > missed that subtests were coming in 1.7 until I saw the release notes, 
> > so I'm playing catchup. 
>
> Could you do a backwards compatibility mode so it would work in go 1.5 
> and 1.6?  If so that would be really useful! 
>
> -- 
> Nick Craig-Wood <ni...@craig-wood.com > -- 
> http://www.craig-wood.com/nick 
>

-- 
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] Shiny

[Sam Boyer]

Yep, this is one of those nasty, known issues with vendoring right now. 
this exact issue was first raised on this list here: 
https://groups.google.com/d/msg/golang-nuts/AnMr9NL6dtc/UnyUUKcMCAAJ. 

We've got a crew coming together soon to address this issue, among many 
others: 
https://docs.google.com/document/d/18tNd8r5DV0yluCR7tPvkMTsWD_lYcRO7NhpNSDymRr8/edit#

On Thursday, August 18, 2016 at 8:19:26 PM UTC-4, howar...@gmail.com wrote:
>
> My poor brain is melting. I was just worried about vendoring shiny and the 
> effect of that on producing something to be easily embedded in other 
> people's programs... while writing a (successful, mind!) wrapper of 
> sigint.ca/graphics/editor that makes it fit the Widget node.LeafEmbed 
> model of shiny... 
>
> And when I tried to pass in mouse events as well as the keyboard events I 
> was already passing, I got this error:
> ./textedit.go:65: cannot use e (type "golang.org/x/mobile/event/mouse".Event) 
> as type "sigint.ca/graphics/vendor/golang.org/x/mobile/event/mouse".Event 
> in argument to t.editor.SendMouseEvent
>
> Sooo the library I am adding to extend the missing functionality in 
> shiny, already vendors shiny and mobile. o_O
> Though, only mobile/event/mouse/mouse.go, which based on its alterations, 
> I assume fits with modifications to their vendored shiny, as otherwise I 
> can't see how it could be filled out. But which means that when embedding 
> in un-vendored shiny, you can't send them any mouse events... as far as I 
> can see, you can't even manually repackage events in the format they want, 
> because you can't import the vendored package from another package.
>
> I also can't just vendor sigint.ca and add a WrapMouseEvent(e 
> unvendoredevent) type call, since the new 1.7 vendoring stuff does 
> automatic rewriting, so I can't get at *both* the vendored *and* the 
> unvendored on either side. I could possibly pass it through as an 
> interface{} and unpack it with reflection (bleh!), or create yet a third 
> mouse.Event that is actually on a different path, so is accessible to both, 
> and convert it twice (ick, but less so). Not really sure where to go with 
> this, but I guess mouse interaction is not critical to my primary intended 
> use... so back to what I was trying to accomplish.
>

-- 
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.

[go-nuts] tbsp - Spoon-feed your table-based tests!

[Sam Boyer]

OK, so this is kind of a lark, but to celebrate the new subtesting system 
 in Go 
1.7, I fired out a quick lib for executing table-based 
tests https://github.com/sdboyer/tbsp.

The implementation is pretty trivial, so I hardly expect people to actually 
import it. But, it's a nice little demonstration of what I think 
table-based testing should generally start to look like, now that subtests 
are a thing.

Sorry if there's already something out there like this - I totally missed 
that subtests were coming in 1.7 until I saw the release notes, so I'm 
playing catchup.


-- 
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.