Hi Scott, thanks for boiling this down to the specific behavior you're
looking for. Is there a specific feature request you'd like to make for
this? If so, please file it in golang.org/issue. Thanks!
S
On Sun, Sep 16, 2018 at 4:01 PM Scott Cotton wrote:
> Hi all,
>
> I just ran a test and
Hi Scott,
Great, it looks like you ran your own test too.
(We had both posted at approximately the same time a few minutes ago).
--thepudds
On Sunday, September 16, 2018 at 4:05:16 PM UTC-4, thepud...@gmail.com
wrote:
>
> Hi Scott,
>
> Regarding your question about pre-release tags and 'go
Hi Scott,
Regarding your question about pre-release tags and 'go get -u', my
understanding is that when the documentation says:
'The -u flag instructs get to update dependencies to use newer minor or
patch releases when available.'
...the use of the phrase 'newer minor or patch release'
Hi all,
I just ran a test and answered my own question:
It does not consider a "prerelease" a "release", so get get -u doesn't
update to prereleases.
In case it helps anyone, this distinction of terminology was unclear to me
in the move to
support prereleases. Apparently, a prerelease is not
Hi Scott,
Modules do provide support for semver pre-release notation. You can read
more about it in these sections of the documentation, for example:
https://tip.golang.org/cmd/go/#hdr-Module_queries
https://tip.golang.org/cmd/go/#hdr-Pseudo_versions
Thanks Sameer,
I have a question about semver and modules, perhaps it was already answered
somewhere, but if so I don't know where.
The question is: semver.org allows for pre-release notation, the document
below does not mention pre-release.
To some extent Go uses pre-releases.
I, for one, find
Thanks. The relationship between semantic versioning and Go packages is
described in detail here: https://research.swtch.com/vgo-import
On Sat, Sep 15, 2018 at 3:52 PM wrote:
> Hi all,
>
> One additional set of brief comments.
>
> This was a fairly nuanced and long thread, and I'm pretty sure I
Hi all,
One additional set of brief comments.
This was a fairly nuanced and long thread, and I'm pretty sure I did not
follow all of it, but I think a question related to the conversation here
is -- what does 'require foo v1.1.1' really mean?
Perhaps one way to think about that usage of the
Thanks! Very useful.
+1 for aliasing "go mod list" to "go list -m"
On 15 September 2018 at 18:59, wrote:
>> "Maybe having a way for "go mod" to output what is used would be less
> confusing?"
>
> Hi all,
>
> To see a list of the selected module versions, one way is to use use 'go
>
> "Maybe having a way for "go mod" to output what is used would be less
confusing?"
Hi all,
To see a list of the selected module versions, one way is to use use 'go
list -m all'. This shows the actual versions used based on all of the
various requirements in a build. Sample output:
$
Thanks for the clarification.
Maybe having a way for "go mod" to output what is used would be less
confusing? I would have found so at least.
Cycles crossing major versions may be more problematic.
similarly in the case of coordinating a collection of modules, dependency
cycles may lead
Go modules can use the listed version or later minor versions. So if B
depends on v1.11 of A, then it can also work with v1.12 of A. Therefore a
valid set of versions for the build is A v1.12 and B v1.3.
On Mon, Sep 10, 2018 at 1:28 AM Scott Cotton wrote:
> Well, ok.
>
> Did you mean if A v1.12
> First, my overall point is that I have decided to use only acyclic
> dependencies, as cyclic ones are too complicated for me.
> I don't feel easily convincible otherwise; that comes from a combination of
> using go modules where some cycles crept in
> and a strong bias for a dead simple
Maybe if I say more it will help the communication/alleviate the
disconnection:
First, my overall point is that I have decided to use only acyclic
dependencies, as cyclic ones are too complicated for me.
I don't feel easily convincible otherwise; that comes from a combination of
using go
Well, ok.
Did you mean if A v1.12 of a module depends on v1.3 of B which depends on
v1.11 of A?
So go modules don't actually necessarily depend on the listed dependencies?
That is quite counteruintintive to me.
It is much simpler in any case to use acyclic dependencies.
Scott
On 10
I think there's a disconnection between how you and I understand this
system works. In a given build, there is only a single version of a module;
there cannot be multiple copies, let alone many copies.So if v1.11 of
module A depends on v1.3 of module B, which in turn depends on v1.12 of
module A,
Hi Sameer,
Thanks for asking, here are some thoughts,
With time, this could create man many many copies of (different versions)
of a module.
this would slow down fetch, storage, compilation, etc potentially a lot,
and it would only
get worse and worse over time.
if a security patch is applied
If a module depends on an earlier version itself, and successive versions
are backwards compatible, why is it not OK for the current version to
satisfy that dependency?
On Sun, Sep 9, 2018 at 1:13 PM Scott Cotton wrote:
> Hi Sameer,
>
> When I had a module self-dependency, I considered the fact
Hi Sameer,
When I had a module self-dependency, I considered the fact that it worked a
bug. I had not followed
closely enough til this discussion to think of it as expected.
As someone who has a tendency to often ask themself: "worse case how can
this be a problem?"
the list is indeed long and
With respect to errors, I'm asking how things failed when you had a cyclic
module dependency. My expectation is that this should just work. If your
module 0.12 has a dependency on itself with min version 0.11, then 0.12
satisfies that dependency (as long as it's following the import
compatibility
Hi Paul,
On 9 September 2018 at 16:26, Paul Jolly wrote:
> Hi Scott,
>
> > Yes I see that in terms of compatibility it "all works out", but it seems
> > underspecified what should happen.
>
> Which bit do you think is underspecified?
>
Perhaps how to ensure a security patch is actually applied
Hi Scott,
> Yes I see that in terms of compatibility it "all works out", but it seems
> underspecified what should happen.
Which bit do you think is underspecified?
To my mind the behaviour is very clearly defined, notwithstanding the
next point.
> Also, although your experience reports are
>
Hi Paul,
Yes I see that in terms of compatibility it "all works out", but it seems
underspecified what should happen. Also, although your experience reports
are
clearly presented and make sense, when I step back my own impression
is: that's not simple. I'd rather be spending time coding than
Hi Sameer,
I don't know what is considered an error and not an error with cyclic
module dependencies.
Honestly, it makes my head hurt and simply requires too much thought that
I'd rather spend on the code.
For example, I don't want to think what will happen to some SCC in a module
dependency
> Interesting. I'm not sure what cyclic module dependencies means. I do know
> some package managers (not go) boast of having a "solid transitive dependency
> model". I hope that any cycles in modules dependencies are either avoided or
> treated in a very clear simple way by go's modules.
Are you seeing errors when there are cyclic module dependencies? As I
recall, cyclic dependencies between modules (not packages) must be allowed:
https://research.swtch.com/vgo-mvs
"Note that F 1.1 requires G 1.1, but G 1.1 also requires F 1.1. Declaring
this kind of cycle can be important when
Hi Paul,
On 9 September 2018 at 13:44, Paul Jolly wrote:
> Hi Scott,
>
> > Should cyclic module dependencies be allowed?
>
> Yes, indeed in some situations they are totally necessary.
>
> I wrote up an experience report on this very topic:
>
Hi Scott,
> Should cyclic module dependencies be allowed?
Yes, indeed in some situations they are totally necessary.
I wrote up an experience report on this very topic:
https://gist.github.com/myitcv/79c3f12372e13b0cbbdf0411c8c46fd5
> Should a module, following a cycle, be able to depend on an
Hi all,
I am wondering about cyclic dependencies w.r.t. modules. I haven't been
able to find anything related, but also haven't verified all the possible
related discussion venues, which would take a while.
Let me start out with an observation: Suppose
module A has packages
A
A/x
29 matches
Mail list logo
