Having an interface between go get and the location of the repositories
should really allow people to move packages around at will provided the
registration of a package provides a canonical import path. (and a facility
for the declaration of mirrors)
Now, to accomodate with vcs and demands for
Indeed, that's where we are coming short. The Go ecosystem does not own its
package releasing process. (with a release identification scheme that may
different from semver since we do not need to worry about major versions
for reasons of different release semantics)
A `go release` command that
>
> That's somewhat the intent in enabling the timestamping of packages
> especially wrt. library-vendored package.
> Flattening dependencies will still be needed but it would be simply a
> matter of switching a package to the latest package release that a package
> may have vendored.
>
>
To do
That's somewhat the intent in enabling the timestamping of packages
especially wrt. library-vendored package.
Flattening dependencies will still be needed but it would be simply a
matter of switching a package to the latest package release that a package
may have vendored.
But again, I would no
On Saturday, 30 July 2016 02:52:25 UTC+2, Matt Harden wrote:
>
> I like submodules, but they do only work when you're using git and only
> vendoring projects that also use git.
>
>
>>
>> It seems to me that the solution is staring us in the face. I know
nothing about git submodules, but they ha
On 7/29/16 5:51 PM, Matt Harden wrote:
> I like submodules, but they do only work when you're using git and
> only vendoring projects that also use git.
Or vendoring any dependency which can be mirrored to git, which is
essentially all of them.
Sam
--
You received this message because you are s
Go is not already opinionated in favor of Github. GitHub happens to be a
popular source code hosting website right now. There's nothing stopping anyone
hosting sources anywhere else as long as the repository is understood by the go
get tool, in cases that's a requirement, else can be something d
That documention is incorrect. The language spec assigns no meaning to the
import path.
The complier assigns the meaning that a compiled package must exists in a
subdirectory with a name that matches the import part, plus .a, in a path
provided by the -I flag.
The go tool goes further to inter
t is hard to do at all, much less broadly and
> elegantly.
>
>
>
> --
>
> Michael T. Jones
>
>
>
> *From: * on behalf of Gregory Golberg <
> deb...@gmail.com>
> *Date: *Friday, July 29, 2016 at 8:54 PM
> *To: *golang-nuts
> *Cc: *
> *Subject: *Re:
: Friday, July 29, 2016 at 8:54 PM
To: golang-nuts
Cc:
Subject: Re: [go-nuts] Re: What lead to the versionning debate?
But it's already a given that Go is fairly opinionated in favor of github, no?
--
You received this message because you are subscribed to the Google Groups
"golang-n
The go tool works with other VCSes, such as mercurial, bitbucket and
subversion.
On Fri, Jul 29, 2016 at 6:47 PM Chad wrote:
>
> On Saturday, July 30, 2016 at 1:43:36 AM UTC+2, Dave Cheney wrote:
>>
>> How about a tag? which developers should be doing as part of any mature
>> release process.
>
On Saturday, July 30, 2016 at 1:43:36 AM UTC+2, Dave Cheney wrote:
>
> How about a tag? which developers should be doing as part of any mature
> release process.
Sure, a tag may be possible. I thought timestamp because it is easily
generated by a machine as well as parsable, with a well define
But it's already a given that Go is fairly opinionated in favor of github,
no?
On Friday, July 29, 2016 at 5:52:25 PM UTC-7, Matt Harden wrote:
>
> I like submodules, but they do only work when you're using git and only
> vendoring projects that also use git.
>
> On Fri, Jul 29, 2016 at 4:44 PM
I like submodules, but they do only work when you're using git and only
vendoring projects that also use git.
On Fri, Jul 29, 2016 at 4:44 PM Gregory Golberg wrote:
> What is wrong with using git submodules inside the vendor directory,
> submodules pointing to the tag/revision of your choice?
>
How about a tag? which developers should be doing as part of any mature release
process.
--
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...@
What is wrong with using git submodules inside the vendor directory,
submodules pointing to the tag/revision of your choice?
On Friday, July 29, 2016 at 10:24:20 AM UTC-7, Chad wrote:
>
> To be more precise, I am not thinking about a package manager but rather
> more of a kind of package registr
To be more precise, I am not thinking about a package manager but rather
more of a kind of package registration interface. A bit like godoc. But
working by submissions of vcs hosts links (thus allowing mirror links).
Backward compatibility requirements are making things simple already: the
late
To be more precise, I am not thinking about a package manager but rather
more of a kind of package registration interface. A bit like godoc. But
working by submissions of vcs links (thus allowing mirror links).
Backward compatibility requirements are making things simple already: the
latest "re
Oh I see now. I guess we need something inbetween go get and the different
vcs to register and timestamp a package each time it is declared as having
been updated. (would still be vcs agnostic though, it's just to timestamp
the package files)
Would make releasing a package a bit more of a manua
Yes, to use the vendor/ feature project authors need to flatten all their
dependencies into a single, top level, vendor/ folder. This is currently
difficult as there is no common way to look at two copies of the same source
code and decode if there are the same, and if not, which should take pri
My reasoning was flawed. (also, I generally mean "one" when I use "we" :)
I think you're right with the project based approach in gb (for people
interested in reproducible builds).
I think that the pkg path issue (that leads to type equality issue) may be
simply solved by having the vendor dire
It's funny that you mention libraries using vendoring because that's been a
big deal surrounding this topic.
https://groups.google.com/d/msg/golang-dev/4FfTBfN2YaI/WCza__MaCgAJ
On Thursday, July 28, 2016 at 4:15:06 PM UTC-7, Chad wrote:
>
> Actually, nevermind. I was thinking about libraries usi
Who is we ? You and me ?
On Friday, 29 July 2016 08:50:47 UTC+10, Chad wrote:
>
> So if we decided that vendoring always used HEAD, that would ideally force
> people to have stable APIs (plus, why vendor an unstable/ in-flight API
> anyway)
>
> Couldn't it enable a change of behaviour for go get
Actually, nevermind. I was thinking about libraries using vendoring. But
that's probably a misuse.
On Friday, July 29, 2016 at 12:50:47 AM UTC+2, Chad wrote:
>
> So if we decided that vendoring always used HEAD, that would ideally force
> people to have stable APIs (plus, why vendor an unstable/
So if we decided that vendoring always used HEAD, that would ideally force
people to have stable APIs (plus, why vendor an unstable/ in-flight API
anyway)
Couldn't it enable a change of behaviour for go get when a vendor directory
is detected and solve some of the issues related to type equalit
Yes, exactly.
--
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/optou
Hi Dave,
Thank you for the link.
>From the discussions I have seen so far, it seems to me that there is a
conflation between the notions of version and revision.
The go tooling AND language remains unaware of revisions indeed, which
would be the role of the source control system (often git now
27 matches
Mail list logo
