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

FIX: correct path semantics behavior #703

Merged
merged 2 commits into from
Mar 27, 2020

Conversation

EliotGann
Copy link
Contributor

This is found with @mrakitin at NSLS-II RSOXS beamline when the collection is done on the Windows machine, and the detector is on a Linux one.

@mrakitin
Copy link
Member

Before making it ready for review, it will be tested with the following scenarios:

  • Linux collection machine + Linux IOC machine (mostly any detector on the NSLS-II floor)
  • Linux collection machine + Windows IOC machine (e.g. PE detector, e.g. at QAS or XPD)
  • Windows collection machine + Linux IOC machine (the GreatEyes detector at NSLS-II RSOXS beamline, see Add GreatEyes detector #704) (already tested)

@klauer
Copy link
Member

klauer commented Mar 14, 2019

Looks like this could be a good step in the right direction! 👍

@gwbischof
Copy link
Contributor

gwbischof commented Mar 14, 2019

You may want to see this @danielballan windows path fix too
danielballan@c350a1f

Copy link
Member

@danielballan danielballan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution! This will be useful at several beamlines. I have left a small but important suggestion.

"""
'a/b/c' -> 'a/b/c/'

EPICS adds the trailing slash itself if we do not, so in order for the
setpoint filepath to match the readback filepath, we need to add the
trailing slash ourselves.
"""
return os.path.join(path, '')
if path_semantics is 'posix':
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should check equality (==) not identity (is). It happens that this works, but we should not rely on it. See for example this StackOverflow answer.

if path_semantics is 'posix':
return f'{PurePosixPath(path)}/'
else:
return f'{PurePath(path)}{os.path.sep}'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider the scenario where ophyd is running on a Linux workstation but the area detector driver is running on Windows, as is the case at some beamlines. In that situation, os.path.sep will return / but the driver needs to be set to \. I suggest something along the lines of:

if path_semantics == 'posix':
    return f'{PurePosixPath(path)}/'
elif path_semantics == 'windows':
    return  f'{PurePath(path)}\'
elif path_semantics is None:
    # We are forced to guess which path semantics to use.
    # Guess that the AD driver is running on the same OS as this client.
    return f'{PurePath(path)}{os.path.sep}'
else:
    # This should never happen, but just for the sake of future-proofing....
    raise ValueError(f"Cannot handle path_semantics={path_semantics}")

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@danielballan, I like the more explicit conditions.
For the Windows part it should be either f'{PurePath(path)}\\\\' or fr'{PurePath(path)}\\' to have \\ returned at the end. Also, I think it should better be PureWindowsPath.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I played with it a bit, and f'{PurePath(path)}\\' should be OK (we need two backslashes to escape a special backslash symbol).

@mrakitin
Copy link
Member

I added the suggested improvement and expanded it to be used in the write_path_template method via d916b18.

@danielballan danielballan marked this pull request as ready for review March 16, 2020 20:37
@danielballan danielballan added this to the 1.4.1 milestone Mar 16, 2020
@danielballan danielballan merged commit c71bd8d into bluesky:master Mar 27, 2020
@danielballan
Copy link
Member

This languished for far too long! Sorry, @mrakitin, @EliotGann, and @RussBerg. This will go out in ophyd v1.4.1 on Monday.

@mrakitin
Copy link
Member

Thank you, @danielballan.

@klauer
Copy link
Member

klauer commented Mar 27, 2020

Just one year? Seems about right...

@mrakitin
Copy link
Member

As a Russian proverb says, "one has to wait for three years for what is promised" 😄

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.

None yet

5 participants