Skip to content

Dependency handling #7

Description

@Ccccraz

Hi, as the number of dependencies involved increases, if managing them is a problem now, for example:

matmoteGO will provide the ability to communicate with cogmoteGO. And I think it should only provide the most basic communication capabilities. More complex functions should be implemented at other levels. matmoteGO depends on: iandol/matlab-zmq. If the project structure is managed using git submodule, it will be:

+matmoteGO
└── matlab-zmq/ (submodule)

If later, opticka uses matmoteGO to develop more complex controls, then opticka's dependencies will be:

+opticka
└── +matmoteGO/ (submodule)
    └── matlab-zmq/ (submodule)

And I believe it is important for opticka to maintain the ability to directly use ZMQ, so it needs to directly depend on matlab-zmq. Therefore, the dependencies of optika will be:

+opticka
├── matlab-zmq/ (submodule)
└── +matmoteGO/ (submodule)
    └── matlab-zmq/ (submodule)

This will cause matlab-zmq to be imported repeatedly. This is clearly not an ideal state.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions