glfw: Enable Gyro support (to more easily add this as a dependency) #181

Closed

BratishkaErik wants to merge 1 commit from gyro into main

BratishkaErik commented

2022-03-14 14:00:24 +00:00

(Migrated from github.com)

By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.

- [X] By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.

emidoots commented

2022-03-19 06:40:44 +00:00

(Migrated from github.com)

I'm not super sure what to do here.

Gyro and zigmod are the two popular unofficial package managers for Zig, and an official one is on the way. Many use submodules today as a workaround. I personally will only be using the official package manager, and in the meantime submodules.

The problem comes in that this introduces a bunch of questions I don't really know how to answer:

If we support Gyro, should we not also support zigmod?
Once the official package manager comes out, can we remove Gyro and zigmod? That doesn't seem nice / like a good citizen, and I imagine would leave us with an "outdated" package on these indexes despite the library otherwise being maintained.
- Do we then commit to maintaining the gyro/zigmod package definition forever going forward?
How do we update & keep the Gyro file / zigmod file up to date? Since I won't be familiar with these tools, it's hard for me to do this. And if a third package manager comes out.. where do I stop?

I totally understand if all these sound like exaggerated concerns, you're just a user of Gyro and want this merged for easier usage on your end.. I'm just worried about the long term impact this will have, and would like to wait a bit longer until package management in Zig calms down a bit before deciding what to do exactly.

I'm not super sure what to do here. [Gyro](https://github.com/mattnite/gyro) and [zigmod](https://github.com/nektro/zigmod) are the two popular unofficial package managers for Zig, and an official one is on the way. Many use submodules today as a workaround. I personally will only be using the official package manager, and in the meantime submodules. The problem comes in that this introduces a bunch of questions I don't really know how to answer: * If we support Gyro, should we not also support zigmod? * Once the official package manager comes out, can we remove Gyro and zigmod? That doesn't seem nice / like a good citizen, and I imagine would leave us with an "outdated" package on these indexes despite the library otherwise being maintained. * Do we then commit to maintaining the gyro/zigmod package definition forever going forward? * How do we update & keep the Gyro file / zigmod file up to date? Since I won't be familiar with these tools, it's hard for me to do this. And if a third package manager comes out.. where do I stop? I totally understand if all these sound like exaggerated concerns, you're just a user of Gyro and want this merged for easier usage on your end.. I'm just worried about the long term impact this will have, and would like to wait a bit longer until package management in Zig calms down a bit before deciding what to do exactly.

👍 2

BratishkaErik commented

2022-03-19 10:34:34 +00:00

(Migrated from github.com)

I'm not super sure what to do here.

Gyro and zigmod are the two popular unofficial package managers for Zig, and an official one is on the way. Many use submodules today as a workaround. I personally will only be using the official package manager, and in the meantime submodules.

The problem comes in that this introduces a bunch of questions I don't really know how to answer:
* If we support Gyro, should we not also support zigmod?

* Once the official package manager comes out, can we remove Gyro and zigmod? That doesn't seem nice / like a good citizen, and I imagine would leave us with an "outdated" package on these indexes despite the library otherwise being maintained.
  
  * Do we then commit to maintaining the gyro/zigmod package definition forever going forward?

* How do we update & keep the Gyro file / zigmod file up to date? Since I won't be familiar with these tools, it's hard for me to do this. And if a third package manager comes out.. where do I stop?
I totally understand if all these sound like exaggerated concerns, you're just a user of Gyro and want this merged for easier usage on your end.. I'm just worried about the long term impact this will have, and would like to wait a bit longer until package management in Zig calms down a bit before deciding what to do exactly.

Ok, new idea :)

> I'm not super sure what to do here. > > [Gyro](https://github.com/mattnite/gyro) and [zigmod](https://github.com/nektro/zigmod) are the two popular unofficial package managers for Zig, and an official one is on the way. Many use submodules today as a workaround. I personally will only be using the official package manager, and in the meantime submodules. > > The problem comes in that this introduces a bunch of questions I don't really know how to answer: > > * If we support Gyro, should we not also support zigmod? > > * Once the official package manager comes out, can we remove Gyro and zigmod? That doesn't seem nice / like a good citizen, and I imagine would leave us with an "outdated" package on these indexes despite the library otherwise being maintained. > > * Do we then commit to maintaining the gyro/zigmod package definition forever going forward? > > * How do we update & keep the Gyro file / zigmod file up to date? Since I won't be familiar with these tools, it's hard for me to do this. And if a third package manager comes out.. where do I stop? > > > I totally understand if all these sound like exaggerated concerns, you're just a user of Gyro and want this merged for easier usage on your end.. I'm just worried about the long term impact this will have, and would like to wait a bit longer until package management in Zig calms down a bit before deciding what to do exactly. Ok, new idea :)

👍 1 ❤️ 1