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

Actually it seems viper imports it with lower case. I don't remember if import paths are to be considered different if they only differ in case. ons 21 feb. 2018 kl 09:04 skrev Henrik Johansson : > I am currently running `vgo build` on a decent sized project that has a >

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

I am currently running `vgo build` on a decent sized project that has a few dependencies. It bailed on import case it seems: import "github.com/spf13/jwalterweatherman": module path of repo is github.com/spf13/jWalterWeatherman, not github.com/spf13/jwalterweatherman (wrong case) This is a

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

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

[go-nuts] Re: intelliji can't access go 1.10 std lib on Mac OS

Maybe something with GOROOT? From the release notes: If the environment variable $GOROOT is unset, the go tool previously used > the default GOROOT set during toolchain compilation. Now, before falling > back to that default, the go tool attempts to deduce GOROOT from its own > executable

[go-nuts] what was learned from the dep experiment

All: So I read Russ Cox post and specifically noted this: "But once we understand the design space better and can narrow it down to the few key features that must be supported, it will help the Go ecosystem to remove the other features, to reduce expressiveness, to adopt enforced conventions

Re: [go-nuts] what was learned from the dep experiment

On Wed, Feb 21, 2018 at 6:19 AM, Joseph Lorenzini wrote: > > So I read Russ Cox post and specifically noted this: > > "But once we understand the design space better and can narrow it down to > the few key features that must be supported, it will help the Go ecosystem > to

[go-nuts] Go Programming Language Course

I'm putting together a 3-credit introduction to the Go programming language at the community college level. I will create (as a minimum) syllabus, outline, lecture notes, handouts, assignments, projects, quizzes and final exam. I will probably start with the Donovan & Kernighan A-W 2015 text.

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

I like this! One question: Some of us commit their `vendor` folder, to be able to build the project without any network access after the initial checkout ("offline mode"). Since the `vendor` folder is gone, is vgo able to manage and use a kind of `mirror` folder, which would contain the .zip

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

Why would that be a mistake? Working with tags and branches is what the VCS is for. Extracting a given version and using that per the convention that the import ends with the major version sounds very reasonable. On Wed, Feb 21, 2018, 22:51 Zellyn wrote: > On Wednesday,

[go-nuts] Re: How to limit what the `go get` command is able to import

Are the builds and deployment controlled? The command “go list” can be used to simplify parsing the imports in each package, so a script could check that every import is either an allowed standard library package or one matching your internal URL. Matt On Wednesday, February 21, 2018 at

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

> [+cc golang-nuts, it was lost at some point] BCC golang-nuts. Please do NOT mix the two threads. I expect that the two different lists with different people will have different focuses for their discussions. On Wed, Feb 21, 2018 at 5:31 PM, Aram Hăvărneanu wrote: > [+cc

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

[+cc golang-nuts, it was lost at some point] I find it unexpected that to compute a version you need information not from one, but from two places that use very similar but ultimately different syntax. In vgo the major version has to be specified in Go import paths, and the minor version needs

[go-nuts] Re: intelliji can't access go 1.10 std lib on Mac OS

Hi, You need to provide more details than this. Have you installed Go in the same location? What version are you using? Have you tried restarting the IDE after the Go install operation? Thanks. On Wednesday, February 21, 2018 at 1:18:22 AM UTC, Joseph Lorenzini wrote: > > All: > > I may just

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

On Wed, Feb 21, 2018 at 11:55 PM David Anderson wrote: > Reading the latest post, https://research.swtch.com/vgo-mvs , a > question... > > It feels to me like there's a missing 5th operation, in additions to the > one you proposed: "upgrade all my *direct* dependencies to their

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

I'm looking forward to see this in official releases too! Also I would like to: - Have a mechanism for safe dependency packages (as in Safe-Tcl - this implies it would be possible to have meta-data other than versions for packages, too). - This one

[go-nuts] Re: Go Programming Language Course

The main value is not adding complexity in your learning setup. As value points you can show examples how to cross-compile from Windows to Linux. Of course, as Jonathan mentioned compiling with C is bit annoying. If you just need to use CGO, then TDM-GCC does a decent job. If you need to link

Re: [go-nuts] Go Programming Language Course

Wasn't Sqlite compiled to Go or something? I remember some news about it, using C to Go compiler. As for the C toolchain for Go, the easiest way to get started on Windows is to install MSYS2 and use pacman to install GCC 64 and then libs like sqlite2 . Le mercredi 21 février 2018 21:49:50

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

Replying to this thread to drop golang-dev. Please try to keep the two threads separate. I should not have used the same subject for each. Sorry. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

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

Reading the latest post, https://research.swtch.com/vgo-mvs , a question... It feels to me like there's a missing 5th operation, in additions to the one you proposed: "upgrade all my *direct* dependencies to their latest version, but keep using minimal versions below that." I don't believe there

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

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? In git we can rename the file in the entire history which messes

Re: [go-nuts] Assign a new value to an already initiated variable in template

Thanks for this example! I realized that to modify a variable I have to add a "var" function to return pointer of an object, then I can use a "set" function to modify it. And in the beginning I also provided "get" function to return the value referenced by the pointer, however later I suddenly

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

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?

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

On Wed, Feb 21, 2018 at 3:55 PM, Axel Wagner wrote: > On Wed, Feb 21, 2018 at 11:55 PM David Anderson wrote: > >> Reading the latest post, https://research.swtch.com/vgo-mvs , a >> question... >> >> It feels to me like there's a missing 5th

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

And also I would like the $GOPATH to stay. I clean it up from time to time - also $GOPATH/bin which go install uses. On Thursday, February 22, 2018 at 9:40:17 AM UTC+3:30, dc0d wrote: > > I'm looking forward to see this in official releases too! > > Also I would like to: > > - Have a mechanism

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

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

Re: [go-nuts] Go Programming Language Course

I develop Go on Windows 10, and it's bearable, but not great. There are missing features (IIRC, plugins only work on Linux/Mac OS) and the lack of a C compiler toolchain can cause problems too (e.g. I couldn't install SQLite as it's a Go binding to C code, and I don't have GCC configured. I guess

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

> > Since the `vendor` folder is gone, is vgo able to manage and use a kind of > `mirror` folder, which would contain the .zip archives of the project > dependencies? This folder could be committed with the project source code. I have the same question. Can we vendor modules? Code consumers

Re: [go-nuts] simple sprintF output question

You’re quoting the help for %x for strings and byte slices. For integers it simply says "base 16, with lower-case letters for a-f” and thus behaves like any other number base usually does. In this case, you want “%02x”. //jb On 21 Feb 2018, at 12:06, David Renne

[go-nuts] simple sprintF output question

https://play.golang.org/p/XZimA47p9qM Why isnt this formatted with two bytes below 10 and is merely 0-9 instead of 00, 01, 02 etc etc with a left padded zero? The documentation of %x for sprintf made me think that this would keep a left padded zero on my string for 0-9, so I merely

[go-nuts] How to limit what the `go get` command is able to import

My company wants to start using go more, and traditionally when we use java and python, when we package them for the developer laptops we override settings and configs for the installs to point to our internal Artifactory so that we don't have developers using packages that haven't been ok'd

Re: [go-nuts] Re: ANN: gijit, a Go interpreter

I've released gijit v1.0.0. This brings over the full typesystem from GopherJS's implementation into the gijit LuaJIT environment. I ported it to windows, and added complex number support. https://github.com/gijit/gi Release v1.0.0 of *gijit* marks these milestones: - the full program

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

On Wed, Feb 21, 2018, at 13:49, Peter Bourgon wrote: > > If not, do I maintain separate /v2 and /v3 trees in my directory and > > copy/paste changes between them when I want to release security fixes as a > > point release? > > Yes, this is what vgo expects. This (and the other alternatives)

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

That's not necessarily true. The tool can understand from the tag and assert or even rewrite the imports to make the compiler happy. On Wed, Feb 21, 2018, 21:51 Sam Whited wrote: > On Wed, Feb 21, 2018, at 14:46, Henrik Johansson wrote: > > But wait. Wasn't there a mention

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

For people who haven't seen it yet: research.swtch.com/vgo-import is the post Sam's referring to. On Wed, Feb 21, 2018 at 2:22 PM, Sam Whited wrote: > Something that is still unclear to me even after reading todays post is > how I would manage the various package import

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

On Wed, Feb 21, 2018, at 14:57, Russ Cox wrote: > My plan is that this is in one of tomorrows' post. Sorry for seeming like > I'm withholding information. I'm posting as they are finished. :-) Sounds good, I look forward to reading it and continuing to digest the proposal. I've had a hard time

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

On Wed, 21 Feb 2018 20:53:20 + Henrik Johansson wrote: > > That's not necessarily true. > The tool can understand from the tag and assert or even rewrite the imports > to make the compiler happy. > > On Wed, Feb 21, 2018, 21:51 Sam Whited wrote: >

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

On Wed, Feb 21, 2018 at 1:10 PM, Bakul Shah wrote: > On Wed, 21 Feb 2018 20:53:20 + Henrik Johansson > wrote: >> >> That's not necessarily true. >> The tool can understand from the tag and assert or even rewrite the imports >> to make the compiler

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

On Wed, Feb 21, 2018 at 11:22 AM, Sam Whited wrote: > Something that is still unclear to me even after reading todays post is how I > would manage the various package import paths created by the import > compatibility rule. > The way this is currently done is through tools

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

Something that is still unclear to me even after reading todays post is how I would manage the various package import paths created by the import compatibility rule. The way this is currently done is through tools such as gopkg.in, will the import path be modified and rewritten by a package

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

On Wednesday, February 21, 2018 at 2:23:07 PM UTC-5, Sam Whited wrote: > > Something that is still unclear to me even after reading todays post is > how I would manage the various package import paths created by the import > compatibility rule. > The way this is currently done is through tools

[go-nuts] Ann: dep_radar - an observer for dependencies

With dep_radar you can see all versions of dependencies among applications. Also, you can set some rules for dependencies: - obligation to have some library - recommended version (>=0.8.0, or =0.8.0) - compulsion to have version, but not a hash - absence of some lib in a project For

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

On Wed, Feb 21, 2018, at 14:46, Henrik Johansson wrote: > But wait. Wasn't there a mention of archive downloads instead of relying on > the different VCS's? > > In the GitHub case I guess it amount to downloading releases (or any commit > I guess) as a zip or tarball. My understanding was that

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

But wait. Wasn't there a mention of archive downloads instead of relying on the different VCS's? In the GitHub case I guess it amount to downloading releases (or any commit I guess) as a zip or tarball. On Wed, Feb 21, 2018, 20:54 Sam Whited wrote: > On Wed, Feb 21, 2018,

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

On Feb 21, 2018 10:11 PM, "Bakul Shah" wrote: On Wed, 21 Feb 2018 20:53:20 + Henrik Johansson wrote: > > That's not necessarily true. > The tool can understand from the tag and assert or even rewrite the imports > to make the compiler happy. > > On

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

On Wed, Feb 21, 2018 at 10:17 PM Peter Bourgon wrote: > ·Any· change to the exported API of a package except adding new > top-level identifiers can be considered an incompatible (breaking) > change. > > https://blog.merovius.de/2015/07/29/backwards-compatibility-in-go.html I

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

On Wed, 21 Feb 2018 22:24:38 +0100 Sebastien Binet wrote: > > On Feb 21, 2018 10:11 PM, "Bakul Shah" wrote: > > > > As v2 is only created due to some incompatible change, in my > > view it is better to have v2 visible in the path. Otherwise > > it is

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

On Wednesday, February 21, 2018 at 4:45:25 PM UTC-5, Bakul Shah wrote: > > Something like > import "foo" v2 > would be mildly preferable to me as > import "foo/v2" > can also refer to version 1 of a package named v2 (as opposed > to version 2 of foo) and the current naming