Skip to content
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

[For Discussion] Version matching core extensions with ezmsg version? #97

Closed
griffinmilsap opened this issue Feb 28, 2024 · 7 comments
Closed

Comments

@griffinmilsap
Copy link
Collaborator

Just a topic for discussion; maybe we should consider version bumping the core extensions (or .. lets just be honest here, mainly the sigproc extension) to match ezmsg's version string?

@griffinmilsap griffinmilsap changed the title Version matching core extensions with ezmsg version? [For Discussion] Version matching core extensions with ezmsg version? May 11, 2024
@cboulay
Copy link
Collaborator

cboulay commented May 30, 2024

I'm not sure if this is the right issue...

So far it seems that it is a bad idea to use poetry to define multiple dependencies that come from the same GitHub repo, but some of them are namespace packages in sub-folders. For example, this line works only the first time:

ezmsg-sigproc = { git = "https://github.com/iscoe/ezmsg.git", branch = "dev", subdirectory = "extensions/ezmsg-sigproc" }

After that first time, a further attempt to do anything with poetry will give the following error:

The dependency name for ezmsg-sigproc does not match the actual package's name: ezmsg.

So I've taken to using the following:

ezmsg = { git = "https://github.com/iscoe/ezmsg.git", branch = "dev", extras = ["sigproc", "zmq"]}

This mostly works, but I still get some errors from it.
I admit that this is mostly a "me and my collaborators" problem because I'm the one asking them to use bleeding edge features that I added to sigproc that haven't made their way into main or pypi yet. Unfortunately, I think that's going to continue to be the case for at least several more months.

Anyway, please consider this my vote for separating out the core namepsace packages (sigproc, zmq, webosckets) into their own repositories.

@griffinmilsap
Copy link
Collaborator Author

Yeahh.. this has been a pain point for me too. I only followed the monorepository (anti?)pattern because Labgraph used this pattern for their extensions...

I'm definitely in favor of breaking out the core extensions.

@cboulay
Copy link
Collaborator

cboulay commented May 31, 2024

Awesome, let's do it!
I'd like to be a maintainer on the sigproc one but I've no preference for websockets or zmq (though I use zmq).

Between all your repos, and these 3 new ones, does it make sense to collect them in one org? Unfortunately there is already a GH user named ezmsg so that's taken. ezmsg-org, ezmsg-ecosystem, ezmsg-framework, my-cat's-name, whatever. You could also keep them in iscoe but I don't know how much they'd like their org being flooded by repos. ETA another suggestion: ezmsg-modules

@griffinmilsap
Copy link
Collaborator Author

I noticed rosneuro did this and it looks pretty sweet. I'm in favor of ezmsg-org.

@cboulay
Copy link
Collaborator

cboulay commented Jun 4, 2024

I tried to create the org but it was asking questions about who is the entity backing the org, etc. I think that should be APL so I think it makes the most sense if you or someone at APL create it.

@cboulay
Copy link
Collaborator

cboulay commented Jun 14, 2024

FYI, I've started the migration. I used this approach to keep the git histories.

https://github.com/orgs/ezmsg-org/repositories

I'm still working on cleaning up this repo to remove their representations and I'll make a PR of that.

@cboulay
Copy link
Collaborator

cboulay commented Jun 14, 2024

Now that they are separate, I think we can also abandon the idea of matching their version strings.

@cboulay cboulay closed this as completed Jun 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants