search

ezmsg-org / ezmsg

Pure-Python DAG-based high-performance SHM-backed pub-sub and multi-processing pattern
https://ezmsg.readthedocs.io/en/latest/
MIT License
9 stars 4 forks source link

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

Closed griffinmilsap closed 3 weeks ago

griffinmilsap commented 4 months ago

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?

cboulay commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

cboulay commented 1 month ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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