-
Notifications
You must be signed in to change notification settings - Fork 8
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
Should we reorganize the root directory? #23
Comments
I agree with these changes, and it would be better done sooner rather than later. |
Perhaps we should move all Python stuff to .
├── Arduino/
│ ├── *
├── configs/
│ ├── *
├── install.sh
├── LICENSE
├── main.py
├── README.md
├── requirements.txt
└── src/ (or sights?)
├── control_receiver.py
├── sensor_stream.py
├── sensor_wrapper.py
├── servo_party.py
├── websocket_process.py
├── utils/
│ └── *
└── sensors/
└── * What's your opinion? |
I agree, The whole file tree you created above could itself be a subdirectory called .
├── docs/
│ └── *
├── .gitignore
│ install.sh
├── LICENSE
├── README.md
├── src/
│ ├── Arduino/
│ │ └── *
│ ├── configs/
│ │ └── *
│ ├── main.py
│ ├── requirements.txt
│ └── src/ (or sights?)
│ ├── control_receiver.py
│ ├── sensor_stream.py
│ ├── sensor_wrapper.py
│ ├── servo_party.py
│ ├── websocket_process.py
│ ├── utils/
│ │ └── *
│ └── sensors/
│ └── *
└── tests/
└── *
This seems to be the structure used by a lot of popular repositories: |
I think I'd prefer the configs in the top level since they're not really source code and it makes it a little clearer that the user is allowed to edit them. Also the apache and motion, etc. configs don't really belong in a src directory. This would be the final structure: .
├── configs/
│ └── *
├── docs/
│ └── *
├── .gitignore
├── install.sh
├── LICENSE
├── README.md
├── src/
│ ├── Arduino/
│ │ └── *
│ ├── main.py
│ ├── requirements.txt
│ ├── control_receiver.py
│ ├── sensor_stream.py
│ ├── sensor_wrapper.py
│ ├── servo_party.py
│ ├── websocket_process.py
│ ├── utils/
│ │ └── *
│ └── sensors/
│ └── *
└── tests/
└── * Or collapsed to show the "cleanliness" of the TLD: .
├── configs/
├── docs/
├── .gitignore
├── install.sh
├── LICENSE
├── README.md
├── src/
└── tests/ |
Moving the configs (the robot configs specifically) up to the top level is a great idea, however, I'd argue that we should keep apache and motion configs away from the user since they are to be used by the SIGHTS installer, and aren't meant to be edited by user. |
How about we move all non-SIGHTS configs to a |
I think it's still too exposed to the user, however we do need to consider users who are using the manual install instructions. I think it's a good compromise. The configs directory has a subdirectory |
Actually I just realised that the motion configs ( |
Actually let's use the |
Good point. Come to think of it I don't think |
Your idea for motion config symlinks is good too, forgot to mention that. |
Brilliant. Sounds like a plan. I'll make a branch and reorganise everything, without fixing dependencies initially, so we can see how it looks. |
Should we rename |
For the config files? .
├── configs/ # User-generated robot configs
│ └── *
├── src/
│ ├─ configs/ # Configs hidden from the user
│ │ ├── sights/ # Used by SIGHTS under normal operation
│ │ │ └── backups/ # Backups generated by SIGHTS
│ │ └── installer/ # Used only by the installer
⋮ ⋮ |
Yeah sorry that was what I meant. Your directory structure is basically what I have at the moment, except I have |
What do you think of https://github.com/SFXRescue/SIGHTSRobot/tree/restructure so far? |
That root directory looks so clean! Is |
Possibly not... Not sure to be honest. I think I'd prefer to have just sensor wrappers in |
Good call. While I do have fond memories of the name |
Holy moly that's a great idea, I never even thought of that. That's far more fitting. Since supervisor and apache2 configs don't need to be updated by the user (but might need to be updated by the SIGHTS updater, hence symlinks) I want to leave them in |
Having |
On the topic of motion config symlinks, how about |
I'm happy with using |
Just to check we're on the same page, you're talking about having the motion config files in Have I got that right? |
I was just thinking of having motion configs in the root |
Ahh, the reverse. Nice, that's probably a better solution. Not sure why I even thought the configs should be in |
We can consider making a few changes before the v1.0 release such as:
src/
perhaps?)sensor_wrapper.py
intosensors/
The text was updated successfully, but these errors were encountered: