-
-
Notifications
You must be signed in to change notification settings - Fork 16k
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
Pip package creation #3357
Pip package creation #3357
Conversation
@sheromon hi I wanted to invite you to contribute to this pip package PR. I know you made some good progress in #2886, but we wanted to start a new PR with a few changes. I'd like to get you on the author list for the change as well though since you did some great work in #2886! One issue we're having is deserializing the currently saved models (saved with the current dir structure) when loading them in the new PR structure. Is this a problem you had in your PR? |
Haha, thanks, @glenn-jocher. I'm not worried about getting credit, I just thought it could be helpful to have the yolov5 namespace. Unfortunately, I don't have any datapoints that would be helpful. I didn't cross-use models created with code using two different directory structures, if that makes sense. I think that's what you're talking about. |
@SkalskiP you could have at least give credit to the original author :) |
@glenn-jocher i have fixed that issue with |
FWIW, in my ideal world, what's in @fcakyon's yolov5-pip repo would get combined with what's in ultralytics/yolov5, but if there are issues with that (and I think that's what I heard), then oh well. Also in my ideal world, I can get in shape by eating Nutella crepes for breakfast, lunch, and dinner, so yeah. |
Hi @fcakyon I'm very sorry that you felt that way. This is just a PR draft for now, where we are trying to consider potential solutions and test them. It is very possible that the target solution will be different. But I have added credits and a link to the original repository. And yes @sheromon and @fcakyon. We are concerned about models that were serialized in the old directory structure but will now be deserialized in the new one. For some reason, we need to use it like that: def attempt_load(weights, map_location=None, inplace=True):
with yolov5_in_syspath():
from models.yolo import Detect, Model So we actually need to import |
@SkalskiP I looked through this a bit. detect.py fails because our example images directory was deleted: Do you know of a way to revert the two deleted files? If not we may need to start a new PR, otherwise the git package will store the newly added files separately than the deleted ones, growing our git download size which we don't want. EDIT: Once I replace the deleted images detect.py works again: EDIT2: I see bus.jpg is pretty large, 473kb, I wonder if we might want to pass it through tinyjpg. Inference results may be slightly worsened, but the filesize would reduce significantly. Unfortunately the git package would only grow though as mentioned before... but the pip package would be reduced right? |
@SkalskiP if I comment out the I don't get a serialization error, I get a model difference error: This is due to the PR Detect and Model modules having different One option for fixing this would be load and re-save all official v5.0 models in a new v5.1 release. detect.py has this checkpoint update capability with the --update flag:
Lines 179 to 182 in ba6f3f9
|
@SkalskiP I've cleaned up the PR a bit, removed some un-needed changes, and applied a few fixes. Everything seems to work correctly now with the sys path fix being required in only one location (attempt_load() in experimental.py). I tested train, test, detect, hubconf, all work. It looks like we have significant conflicts built-up over the week of master updates though, and we need to figure out how best to revert the data/images directory deletion if possible. EDIT: Perhaps rather than fix the conflicts would it make more sense to start a new PR with the same changes, retaining the data/images directory? |
Thanks, @glenn-jocher I'll take a look at those changes right now. Just from reading your comments:
|
β¦ebase_to_prepare_for_pip_package_creation' into feature/restructuring_yolov5_codebase_to_prepare_for_pip_package_creation
@SkalskiP i have a bit of experience with pip packaging, glad to be helpful here :) |
@glenn-jocher and @fcakyon my opinion is:
|
@glenn-jocher I cleaned up and removed those |
@glenn-jocher, @fcakyon what do you thank? Are there are any more changes we should do? :) |
@SkalskiP I see what you say in #3357 (comment), but in the real world users are going to do what they like, not what we tell them, so they will |
β¦prepare_for_pip_package_creation
|
@SkalskiP @fcakyon thanks for the updates guys! I'm not sure what the best technical approach is here, but in terms of UX, we require minimization of breaking changes as an absolute priority. Remember we're not launching a new product here, we're updating a mid-lifecycle product, so this is not the appropriate moment for drastic changes to well established user workflows. Keep in mind there are countless tutorials and videos on YouTube, Medium, Reddit, etc. about how to train and deploy YOLOv5 using universally established python norms like Our demographic also skews heavily towards novices in the field who may just be getting started with python, we don't want to create any barriers to entry or possible pain points, instead we want things to "just work" as Jobs used to say. |
@SkalskiP @fcakyon maybe another option is to push as many updates as makes sense (such as #3382 for train, test, detect, export) to This might allow for easier maintenance for @fcakyon and give us some time to explore minimal-impact solutions with the least breaking changes. Then once we find the best solution the final pip PR would be trivial or at least less complicated. |
@glenn-jocher I understand all your concerns. However, in my opinion, pip package code distribution is an obvious step forward. This would allow many users to incorporate yolov5 into their projects much more easily. Giving up this significant improvement for such (in my opinion) minor reasons as adding an extra level of directory depth and potentially (but not mandatorily) a different installation method is a mistake. As you know, yolov5 has quite a bit of technology debt, and if we don't have the ability and space to change anything in the future for similar reasons as we have today, it's hard to see how we can implement the plans we discussed. I also do not quite understand the "just work" argument, as using Regardless, if you want to take the "baby steps", then I would say, keep Let me know what you decided :) |
I took the time and I looked through some open source repositories and here is what I found:
I found more examples, but I think these few already illustrate quite well that pip package is a must-have and certainly a step in the right direction. |
β¦prepare_for_pip_package_creation
β¦ebase_to_prepare_for_pip_package_creation' into feature/restructuring_yolov5_codebase_to_prepare_for_pip_package_creation # Conflicts: # .github/workflows/ci-testing-requirements-install.yml
|
β¦prepare_for_pip_package_creation # Conflicts: # requirements.txt # yolov5/utils/general.py
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions YOLOv5 π and Vision AI β. |
π οΈ PR Summary
Made with β€οΈ by Ultralytics Actions
π Summary
Enhancements to Ultralytics' YOLOv5 Docker, GitHub CI workflows, and Python compatibility checks.
π Key Changes
setup.py
for easier installs and imports.setup.py
makes it possible to install YOLOv5 as a local package usingpip install -e .
.π― Purpose & Impact