Skip to content
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

hooks: update pydicom hook for compatibility with pydicom v3.0.0 #796

Merged
merged 2 commits into from
Sep 14, 2024

Conversation

rokm
Copy link
Member

@rokm rokm commented Sep 10, 2024

Update the hidden imports for renamed and extended set of plugin modules, and collect the data files that are now required at run-time due to pydicom.examples being imported during pydicom module initialization.

Closes #795.

Update the hidden imports for renamed and extended set of plugin
modules, and collect the data files that are now required at
run-time due to `pydicom.examples` being imported during `pydicom`
module initialization.
@bersbersbers
Copy link

Works great for me, thanks!

@bwoodsend
Copy link
Member

bwoodsend commented Sep 10, 2024

I think we're going to have to make a fuss upstream about those examples. It looks to me like they wouldn't exist at build time in a fresh (e.g. CI/CD) environment so the resultant application would have to redownload everything every time in onefile mode, be shot to pieces by the macOS sandbox and run afoul of permission errors if installed in a read only location. I'll have a proper look (and possible moan) tomorrow when I'm more awake.

@rokm
Copy link
Member Author

rokm commented Sep 10, 2024

I think we're going to have to make a fuss upstream about those examples. It looks to me like they wouldn't exist at build time in a fresh (e.g. CI/CD) environment so the resultant application would have to redownload everything every time in onefile mode, blow up the macOS sandbox and run afoul of permission errors if installed in a read only location. I'll have a proper look (and possible moan) tomorrow when I'm more awake.

On linux, the downloaded files seem to go into ~/.pydicom/data, so this does not violate the immutability of the frozen application bundle. But I agree that it is a bit of a WTF, especially since there is no reason for this import to exist.

@bwoodsend
Copy link
Member

bwoodsend commented Sep 12, 2024

I guess that's not quite so bad then. I raised pydicom/pydicom#2131 anyway. We'll see what they think. Is it worth putting an import pydicom into the hook to avoid the examples not packaged because the application was built on a clean CI machine scenario?

@rokm
Copy link
Member Author

rokm commented Sep 12, 2024

Is it worth putting an import pydicom into the hook to avoid the examples not packaged because the application was built on a clean CI machine scenario?

I don't think so - some of those files are part bundled with the package (and we collect those), while some of them are downloaded on first import (and we do not collect those, because they are not part of the package).

@bwoodsend
Copy link
Member

I think we can get away without test_files?

@bwoodsend
Copy link
Member

Ugh forget it. If I rm -rf my site-packages/pydicom/data/test_files then the next import pydicom doesn't fill ~/.pydicom with anything new. But reading the code seems to imply it should download them as you say.

@bwoodsend
Copy link
Member

Hopefully that redundant import pydicom.examples will disappear.

@rokm
Copy link
Member Author

rokm commented Sep 12, 2024

Hmm, you might be right. Because they are not in the urls.json, it doesn't actually try to download them.

So the dictionary ends up like this (for frozen application with test_files patterns removed):

{'ct': None,
 'dicomdir': None,
 'jpeg2k': '/home/rok/.pydicom/data/US1_J2KR.dcm',
 'mr': None,
 'no_meta': None,
 'overlay': '/home/rok/.pydicom/data/MR-SIEMENS-DICOM-WithOverlays.dcm',
 'palette_color': '/home/rok/.pydicom/data/OBXXXX1A.dcm',
 'rgb_color': '/home/rok/.pydicom/data/US1_UNCR.dcm',
 'rt_dose': None,
 'rt_plan': None,
 'rt_ss': None,
 'waveform': None,
 'ybr_color': '/home/rok/.pydicom/data/color3d_jpeg_baseline.dcm'}

Avoid collecting all data files from `test_files` directory, even
the ones that are referenced `_DATASETS` dictionary that is
constructed during initialization of `pydicom` module in v3.0.0.

It seems that these files are not listed in `urls.json` so even if
they are missing, not attempt is made to download them. If anyone
requires these test files in their frozen application, they should
explicitly collect the files themselves (same as with earlier
versions of `pydicom`).
@bwoodsend
Copy link
Member

Meh, it's up to you. If pydicom/pydicom#2131 goes where I think it'll go then there's a good chance that we won't need any of them.

@rokm
Copy link
Member Author

rokm commented Sep 12, 2024

Let's try getting away without collecting them, then. I've pushed a separate commit so that we have this documented in (the unlikely) event that we end up having to collect them after all.

@rokm rokm merged commit 4bdb42c into pyinstaller:master Sep 14, 2024
14 checks passed
@rokm rokm deleted the hook-pydicom-3.0.0 branch September 14, 2024 09:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Hidden imports not found with pydicom 3
3 participants