Skip to content

Dependency handling #7

@Ccccraz

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.

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