profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/matloob/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Michael Matloob matloob Google New York

google/skylark 1162

Skylark in Go: the Skylark configuration language, implemented in Go [MOVED to go.starlark.net]

matloob/contributing 38

CONTRIBUTING: The Talk

matloob/regexp 34

go regexp with RE2 DFA matcher port - golang.org/cl/12081

matloob/screen 1

screen printing stuff

matloob/check 0

A set of utilities for checking Go sources

matloob/DefinitelyTyped 0

The repository for high quality TypeScript type definitions.

matloob/go-tools 0

Staticcheck – a collection of static analysis tools for working with Go code

issue commentgolang/go

proposal: cmd/go: add a `go mod addwork` command

Modules can still be removed by go mod editwork, and go mod addwork will remove any modules that match the pattern but don't exist on disk.

matloob

comment created time in 11 days

issue openedgolang/go

cmd/go: ensure that workspace mode loads same graph regardless of path

See golang.org/cl/348649 for an example of where this doesn't happen.

created time in 18 days

issue commentgolang/go

cmd/go: add a workspace mode

Since this proposal has been accepted, and there've been a couple of proposals for modifications, we should continue the discussions for new modifications (and make proposals for other modifications) on new issues.

I've broken out @jayconrod and @ianthehat 's proposals into their own issue. (I might have colored them with my own opinions, so @jayconrod and @ianthehat, please continue to advocate for your preferences.

Here are the proposal issues:

  • go workspace / go work subcommand namespace: #48256
  • go workspace add / go mod addwork subcommand: #48257
  • go workspace sync / go mod syncwork subcommand: #48258
  • Using .mod files instead of directories and the use directive: #48259
matloob

comment created time in 20 days

issue commentgolang/go

Proposal: use go.mod file paths in workspaces

Personally I could go either way on this proposal, but I wanted to move this out into its own issue so we could have the discussion on a separate isuse.

matloob

comment created time in 20 days

issue openedgolang/go

Proposal: use go.mod file paths in workspaces

This issue proposes an amendment to the Workspace proposal (#45713) to use go.mod file paths rather than directory paths in the directory directive, perhaps renaming the directive to use. It was originally suggested by @ianthehat in an issue comment:

Now this proposal is accepted, I would like to suggest some minor changes.

I think that we should change it from listing directories (and implying the go.mod file in that directory) to explicitly listing the mod file. I think this would remove some of the confusion about exactly what it means to refer to a directory, and would also allow us to add directories with one of the meanings people have asked for in the future if we wanted to. The cost is negligible, basically existing lines would just need /go.mod appended to the end, and for the most part those lines are written by a tool anyway. This approach would also increase the flexibility of the system by allowing the go.work file to refer to module files not called go.mod. The go command already allows you to use this files in normal module mode, the two uses I know the most about are go.tools.mod and gopls.mod, but there are other uses as well. This would allow you for instance to have a tools.work file that referred to the go.tools.mod files instead of the go.mod files. If we did this, we would also need to change the name of the directive (from directory). I don't really mind what to, I was thinking something like use or include, but suggestions are welcome. The end result would be (using the same example as the proposal)

go 1.18

use (
    ./baz/go.mod // foo.org/bar/baz
    ./tools/go.mod // golang.org/x/tools
)

replace golang.org/x/net => example.com/fork/net v1.4.5

cc @bcmills @jayconrod

created time in 20 days

issue openedgolang/go

Proposal: cmd/go: add a `go mod syncwork` command

This issue proposes amending the Workspaces Proposal (#45713) to add a new go mod syncwork command.

go mod syncwork would compute the buildlist from the workspace modules, and then sync it back to the workspace module go.mod files, setting the versions of any non-workspace modules to the versions in the build list (perhaps also tidying the files afterward). This ensures that the workspace modules use the same set of non-workspace dependencies when they're built outside the workspace.

A version of this was suggested by @jayconrod on an issue comment on the Workspaces proposal.

cc @bcmills @ianthehat

created time in 20 days

issue openedgolang/go

Proposal: cmd/go: add a `go mod addwork` command

This proposal is an amendment of the Go Workspace Proposal (#45713) originally suggested by @jayconrod in a comment on that issue:

I'd like a way to add all modules in a subtree to a workspace using wildcards. Specifically, I'd like go workspace add ./....

  • go workspace use would be a better subcommand name if we end up using that in go.work.
  • I think this would help build a more familiar environment for folks used to working on related projects in GOPATH. I could put a go.work file in $GOPATH/src, then just have one VSCode window for all projects.
  • We've talked about supporting wildcards in go mod initwork and go mod editwork, but that breaks some parallelism with go mod init, which only creates an empty go.mod file, and go mod edit, which only performs low-level syntactic edits without extra processing.

This proposal would add a new go command subcommand, perhaps called go mod addwork (if #48256 is accepted, the new subcommand would be called go work add or go work use).

It would ensure that the go.work command contains modules denoted by the given pattern, removing any matches of the pattern that no longer exist on disk.

cc @bcmills @ianthehat

created time in 20 days

issue openedgolang/go

Proposal: put workspace commands in their own namespace

This proposes an amendment to the Workspaces Proposal #45713, that was originally suggested by @jayconrod (with a small tweak from me).

Instead of naming the commands to create and edit go.work files go mod initwork and go mod editwork, name them go work init and go work edit. This makes future subcommands (such as the proposed add and sync subcommands) have more clear names.

@jayconrod's comment proposed the names go workspace init and go workspace edit.

cc @ianthehat @bcmills

created time in 20 days

issue commentgolang/go

cmd/go: add a workspace mode

On use and specifying .mod files:

I haven't really loved the name directory and saying "directory directive" is definitely awkward. I think "use" along with .mod files could be more clear than specifying directories with the directory directive. @ianthehat, under your proposal, would we still be able to specify directories to go mod editwork and go mod initwork? If not, that would make the commands more awkward. On the other hand, if we did, and most users specify directories all the time, would it be a good idea to have the entity provided in the file to be different than what's usually provided on the command line?

I think it is very unclear what it means to "use" a directory, and until we decide that using a go.mod is much clearer, I cannot think of any way that doing so increases confusion?

I didn't completely understand this sentence. You're saying that we should only adopt "use" if we also change the argument to the directive to be a .mod file, right?

On putting the commands into a new namespace:

We initially chose to make initwork and editwork subcommands of go mod because it wasn't clear that there would be more subcommands. I think it's becoming clear that we'll at least have one or two more (sync and maybe also add). If we put the commands under a namespace, I'd prefer work to workspace. We already use the word "work" as an abbreviation of workspace in the go.work filename, so I think its meaning should be clear to users.

On add:

I agree that we should have a mechanism for adding all the modules contained under a directory. I don't see the same problem that you do for adding to go mod initwork because it's already broken parallelism with go mod init by allowing users to specify multiple directories to be added to the workspace. On the other hand, one nice thing about adding a new command is that we could also have it remove modules that don't exist under the given directory anymore.

On sync:

I think it's a useful operation, and think we should add it, but I wonder if its existence could cause confusion for users because it would do only "half" of what users want. It would sync the dependencies that are not in the workspace, but the dependencies in the workspace still need to be updated by tagging and releasing new versions and updating the requirements on them. And the latter is out of scope for the go command.

matloob

comment created time in 25 days

issue commentgolang/go

proposal: cmd/go: add a workspace mode

@ohir Thanks for the feedback! I'm glad the proposal is working for your use case!

I think the behavior you reported is working as intended though. Even though the workspace module versions override the replaced versions, Go will still check each of the workspace's go.mod files for validity, which includes checking required / replaced versions are valid. To check versions are valid, the go command will check that a go.mod exists at that version.

matloob

comment created time in a month

GollumEvent

issue commentgolang/go

proposal: cmd/go: add a workspace mode

I’ve prepared a video demo here: https://youtu.be/wQglU5aB5NQ

matloob

comment created time in a month

created tagmatloob/schmutzie_dog_tools

tagv1.0.0

created time in a month

create barnchmatloob/schmutzie_dog_tools

branch : main

created branch time in a month

created tagmatloob/schmutzie_dog_names

tagv1.0.0

created time in a month

create barnchmatloob/schmutzie_dog_names

branch : main

created branch time in a month

created repositorymatloob/schmutzie_dog_names

created time in a month

created repositorymatloob/schmutzie_dog_tools

created time in a month

GollumEvent
GollumEvent
GollumEvent

issue commentgolang/go

proposal: cmd/go: add a workspace mode

@marwan-at-work Reached out to you offline. Pairing to debug sounds good.

@marto-r We're still working on exactly what our messaging should be. As I understand your case, (please correct me if I'm wrong!) your repository is split into multiple modules for historical reasons: originally the components were different modules, and they were later moved into the same monorepo, but it's too late to put everything in a single module now. And your use case is that you'd be using workspaces to effectively turn everything into a single module. Is that correct? If so, I think checking in a go.work file could be reasonable. That is, if everyone who works with any of the modules always works with all of them together all the time, I think it's reasonable to check in a go.work file. I do wonder though if there's a better solution, such as some sort of migration path for combining the component modules into a a single module.

And I think that case is extremely rare outside a closed-source business setting where everyone works in a uniform environment. So I think we want to be really careful about how we recommend checking in go.work files, because they really don't belong in any case where all the modules are not always used together. Which might mean more nuance in the recommendation against checking go.work files, but would still mean strongly advising against it.

matloob

comment created time in 2 months

PR opened matloob/startwork

startwork: add framework of startwork command and a test.
+186 -0

0 comment

5 changed files

pr created time in 2 months

push eventmatloob/startwork

Michael Matloob

commit sha aaab412a05abb15901173293bd438ee43a6565c2

beginning of history

view details

Michael Matloob

commit sha d4bb2a5af178c6494cb3773e16807e42a8cfaa37

startwork: add framework of startwork command and a test.

view details

push time in 2 months

create barnchmatloob/startwork

branch : dev

created branch time in 2 months

create barnchmatloob/startwork

branch : main

created branch time in 2 months

created repositorymatloob/startwork

created time in 2 months

issue commentgolang/go

proposal: cmd/go: add a workspace mode

@myitcv My understanding is that gotip downloads and installs its version of Go in $HOME/sdk/gotip, so you can change your environment in the gopls settings so that it picks go from $HOME/sdk/gotip/bin/go. Altearnatively, if you're using gopls through vscode, you should be able to set go.alternateTools to point to gotip.

matloob

comment created time in 2 months

issue commentgolang/go

proposal: cmd/go: add a workspace mode

Hi! I’ve got a prototype ready to try out!

To run:

go get golang.org/dl/gotip gotip download dev.cmdgo

then use gotip as your go command!

matloob

comment created time in 2 months

issue commentgolang/go

x/tools/go/analysis/analysistest: output and golden file differ, but RunWithSuggestedFixes does not report failure

Looking at the CL it seems like not reporting an error was an oversight. I can't think of a good reason to just ignore that case

nishanths

comment created time in 2 months