-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
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:
After that first time, a further attempt to do anything with poetry will give the following error:
So I've taken to using the following:
This mostly works, but I still get some errors from it. Anyway, please consider this my vote for separating out the core namepsace packages (sigproc, zmq, webosckets) into their own repositories. |
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. |
Awesome, let's do it! 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 |
I noticed rosneuro did this and it looks pretty sweet. I'm in favor of |
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. |
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. |
Now that they are separate, I think we can also abandon the idea of matching their version strings. |
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?
The text was updated successfully, but these errors were encountered: