search

opendr-eu / opendr

A modular, open and non-proprietary toolkit for core robotic functionalities by harnessing deep learning
Apache License 2.0
619 stars 95 forks source link

fix(efficientLPS): Fix the dependency conflict of geffnet installation #410

Closed aselimc closed 1 year ago

aselimc commented 1 year ago

This PR aims to fix the dependency error between EfficientPS and EfficientLPS. EfficientLPS is unable to use efficientNet (geffnet) library that can be installed using EfficientPS even though the versions are same. The reason is because original efficientNet library is modified for EfficientLPS. However, EfficientPS is still compatible with the modified version. That is why I have added a small trick when python_dependencies.txt file is being created by dependencies/parse_dependencies.py.

ad-daniel commented 1 year ago

On a side note, I've noticed that whenever installing the toolkit a diff is created in the EfficientLPS submodule, specifically: opendr/src/opendr/perception/panoptic_segmentation/efficient_lps/algorithm/EfficientLPS

b

It's not a big deal, but rather an annoyance (being a submodule I need to cd into it to clear it every time I switch branches). Any chance we can get rid of this?

tsampazk commented 1 year ago

On a side note, I've noticed that whenever installing the toolkit a diff is created in the EfficientLPS submodule

I can confirm that I've been having this issue too pretty randomly on and off in the past months.

aselimc commented 1 year ago

On a side note, I've noticed that whenever installing the toolkit a diff is created in the EfficientLPS submodule, specifically: opendr/src/opendr/perception/panoptic_segmentation/efficient_lps/algorithm/EfficientLPS

b

It's not a big deal, but rather an annoyance (being a submodule I need to cd into it to clear it every time I switch branches). Any chance we can get rid of this?

Ah sorry I totally forgot to respond to this. Well, this happens randomly in my setup as well, but I think the reason is because when submodule packages are installed, they tend to create this version.py and/or modify existing packaging info etc. I have not figured out how to prevent this, but as you have written this is not a big deal, so I would suggest we merge this and handle the other problem separately.