New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

module-aware building #855

Open
hajimehoshi opened this Issue Aug 26, 2018 · 9 comments

Comments

Projects
None yet
5 participants
@hajimehoshi
Member

hajimehoshi commented Aug 26, 2018

Now Go 1.11 introduces module-get, I suggest to change gopherjs build or other commands to be module-aware. For example, I'd want the below code to be workable:

mkdir foo
cd foo
go mod init example.com/m
go get github.com/gopherjs/gopherjs
gopherjs build -tags=example github.com/hajimehoshi/ebiten/examples/sprites@master
@myitcv

This comment has been minimized.

Collaborator

myitcv commented Sep 7, 2018

FWIW I have module-aware building in branch go1.11 of my fork at https://github.com/myitcv/gopherjs

@hajimehoshi

This comment has been minimized.

Member

hajimehoshi commented Oct 25, 2018

@myitcv I discussed with @dmitshur , and we agreed that it is fine to merge your module-aware building. I'd be happy if you could make a PR. Thanks!

@myitcv

This comment has been minimized.

Collaborator

myitcv commented Oct 26, 2018

@hajimehoshi back in April I raised #799. As a follow up to that, and to discuss my open PRs, @dmitshur and I had a call in which Dmitri said that his plan was to "sunset" GopherJS with the arrival of experimental WASM support in Go 1.11. Hence he did not want to grant access to additional people or accept any more PRs, other than a PR he was working on for Go 1.11 support (and potentially in other exceptional circumstances). Hence Dmitri's suggestion was to do things in a fork, which is how https://github.com/myitcv/gopherjs came about.

Has that position now changed?

As I suggested to Dmitri on our original call, perhaps we could also get some clarification on the current position (with respect to the https://github.com/myitcv/gopherjs fork) added to the main README so anyone else considering contributing a PR is clear.

Thanks

@hajimehoshi

This comment has been minimized.

Member

hajimehoshi commented Oct 26, 2018

Has that position now changed?

Thank you for elaborating and sorry for my lack of explanation. This position is not changed basically, but I asked @dmitshur that I am eager to have module support of GopherJS. @dmitshur permitted me that under the condition of my review and taking care of. But right, this change seemed to be conflicting with the current policy of GopherJS. We need to be on the same page.

IMHO, GopherJS is still useful for a while even after Wasm comes since Wasm still has several problems (e.g. OOM at mobile browsers golang/go#27462, bigger binary size than GopherJS, etc.) so Wasm cannot become a complete substitute of GopherJS so far. Actually I cannot finish to switch to Wasm for my libs yet.

As I suggested to Dmitri on our original call, perhaps we could also get some clarification on the current position (with respect to the https://github.com/myitcv/gopherjs fork) added to the main README so anyone else considering contributing a PR is clear.

+1.

@myitcv

This comment has been minimized.

Collaborator

myitcv commented Oct 28, 2018

This position is not changed basically

Thanks for clarifying @hajimehoshi. Personally I think it's a bit of a shame that various of my own and indeed a number of others' contributions have been left hanging for so long.

In #799 (back in April) I offered to help in a more formal capacity on the back of a number of issues, PRs and Slack contributions I had worked on/made in the past. Again I find it a bit unfortunate that an offer like this has been ignored and kicked into the long grass.

IMHO, GopherJS is still useful for a while even after Wasm comes since Wasm still has several problems (e.g. OOM at mobile browsers golang/go#27462, bigger binary size than GopherJS, etc.) so Wasm cannot become a complete substitute of GopherJS so far. Actually I cannot finish to switch to Wasm for my libs yet.

This was and remains my position too. But Dmitri wanted to "sunset" GopherJS. Hence he did not want to grant access to additional people or accept any more PRs, other than a PR he was working on for Go 1.11 support (and potentially in other exceptional circumstances). Hence he suggested that I work in a fork.

Therefore, if it's all the same with you, I will continue to offer what module support I can in my fork.

@mvdan

This comment has been minimized.

mvdan commented Nov 5, 2018

I think some action needs to happen here. Option A is to not stop project development and welcome new (old?) contributors.

Option B is to actually bring the project to a halt, making that clear in the README and linking to active forks that may be interesting to the reader. The same would apply if the project was kept in maintenance mode, only to add support for Go 1.12, 1.13, etc.

I think leaving the project in this limbo state is unhealthy for both developers and users. Developers have no idea if they should send PRs or otherwise contribute to the project, and users are left requesting features in the issue tracker when it's very unlikely any of the developers will read them.

Please note that this is not a demand nor going against anyone in particular. I just wish that working on and with GopherJS wasn't this difficult.

@flimzy

This comment has been minimized.

Contributor

flimzy commented Nov 5, 2018

Option A is to not stop project development and welcome new (old?) contributors.

Is this somehow different than what we have at the moment?

I don't see a problem to be solved, or a proposed solution here.

@mvdan

This comment has been minimized.

mvdan commented Nov 5, 2018

Paul's links above are a good example: #799 https://github.com/gopherjs/gopherjs/pulls/myitcv

Solution A is to approve #799, let the PRs that make sense be merged, and close the others. As the project stands now, it has over 20 open PRs, most of which have had zero attention in the past year. To me, that says that sending a PR to this project is just not worth anyone's time.

I can understand if current maintainers don't have the time to keep up with incoming issues and PRs. This is precisely why new maintainers should be welcome on board, as long as design decisions are still made with consensus.

@dmitshur

This comment has been minimized.

Member

dmitshur commented Nov 7, 2018

I think leaving the project in this limbo state is unhealthy for both developers and users. Developers have no idea if they should send PRs or otherwise contribute to the project, and users are left requesting features in the issue tracker when it's very unlikely any of the developers will read them.

This is true, and very unfortunate.

It has taken a lot of my time maintaining and developing GopherJS the last year, when I was on a sabbatical and working on open source full time. I now have a full time job (which involved going through the process of relocation), and have much less free time to spend on contributing to GopherJS.

I haven’t done a great job of finding a way for this open-source project to continue to be healthy.

I think some action needs to happen here.

I agree. I’m doing my best to figure out how to move forward. I’ve made some progress recently, and I’ll share updates soon. I just wanted to say I’m fully aware of the problem and am trying to resolve it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment