Open dagewa opened 14 hours ago
This is the immediate cause of this test failure on Windows https://github.com/xia2/xia2/pull/824#issuecomment-2491813579
In this case, paths()
is
In [11]: iset.paths
Out[11]: <bound method _.paths of <dxtbx.imageset.ImageSetLazy object at 0x000001CCFBEB6A70>>
ImageSetLazy
Should we be expecting to see this anywhere outside of stills_process? I thought this was only for handling inside there?
No idea about ImageSetLazy
...
Short reproducer of the issue
>>> from dxtbx.model.experiment_list import ExperimentList
>>> el=ExperimentList.from_file("C:/Users/fcx32934/.cache/dials_data/dtpb_serial_processed/well39_batch12_integrated.expt", check_format=False)
>>> el[0].imageset.paths()
['c:\\dls\\mx\\data\\nt30330\\nt30330-15\\VMXi-AB1698\\well_39\\images\\image_58763.nxs']
.. I think that this handling is possibly necessary because we retain the ability to have relative path names, which AFAIK we only use in tests? If this was always required to be absolute, we could probably skip this?
Or alternatively, only do this replacement if it ends up pointing to a file that actually exists, otherwise leave it as the original filename?
Damn, your mention of resolve_path
triggered some stirring of the grey matter and I went back and found this https://github.com/cctbx/dxtbx/issues/613. I have been in this dungeon before.
I wonder if this is actually the best way to resolve:
only do this replacement if it ends up pointing to a file that actually exists, otherwise leave it as the original filename?
That makes a lot of sense
This code in DIALS gets called by
xia2.ssx_reduce
:The call to
iset.paths()
on Windows returns something like thisThe original path (a location on the DLS file system) has been manipulated by adding a drive letter and altering the path separator. This causes a failure later on when these paths are checked against cached file names in a dictionary (
if iset == ifile.name
), because the manipulated path does not match the expected path and we end up with