-
Notifications
You must be signed in to change notification settings - Fork 76
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
DEV: Fix editable install on Windows #1218
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1218 +/- ##
=======================================
Coverage 77.99% 77.99%
=======================================
Files 90 90
Lines 7179 7179
=======================================
Hits 5599 5599
Misses 1580 1580 Continue to review full report at Codecov.
|
Yes, this looks good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the middle of the review, but I'm happy I was able to install without admin rights! I am going to advocate for one thing though: I think we should move away from os.path
and move towards pathlib.Path
. IMO I think it's a lot easier to work with and clearer to read. I've added a few examples of how I think it could work, but haven't tested it
setup.py
Outdated
if not is_win: | ||
rel_source = os.path.relpath(os.path.abspath( | ||
source), os.path.abspath(target_subdir)) | ||
else: # relpath does not work if source/target on different Windows disks | ||
rel_source = os.path.abspath(source) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't fully grok what's happening here, but I have a suspicion that this isn't necessary if you use Paths. You can always switch between absolute and relative paths with Path.absolute()
and Path.relative_to(yourPath)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
relative_to does not work if one is relative and the other one absolute, so you still need abs path for both to be safe.
setup.py
Outdated
if not is_win: | ||
os.symlink(rel_source, target) | ||
else: # Cannot symlink without relpath or Windows admin priv in some OS versions | ||
shutil.copytree(rel_source, target) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not try the symlink in case the user DOES have admin rights?
if not is_win: | |
os.symlink(rel_source, target) | |
else: # Cannot symlink without relpath or Windows admin priv in some OS versions | |
shutil.copytree(rel_source, target) | |
try: | |
rel_source.symlink_to(target) | |
except: # Cannot symlink without relpath or Windows admin priv in some OS versions | |
shutil.copytree(rel_source, target) |
Also I always forget the direction of the symlink. Did I get the direction right here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
try-except is more trouble than it's worth because I am trying to fix two different problems on Windows with the same logic:
- Both our problems: Admin priviledge
- My problem: My source checkout is on D but my Miniconda is on C
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I think if you try to symlink on Windows, you will need admin priv, no?
Co-authored-by: Duy Tuong Nguyen <[email protected]>
Undo overzealous Path replacements.
@duytnguyendtn , I tried to use Path as much as I can. Seems to work for me both natively on Windows (no symlink) and on WSL2 Debian (symlink), but you should double check. If you still feel uncomfortable, please remove the "trivial" label and get another dev (preferable on Mac OSX) to vet this. They should see the template stuff symlinked to the desired destination. For me, it went to a place under |
tagging @vidartf in case he's interested in having a windows solution to a dev install for voila templates. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes! Install worked like a charm on Windows! Unfortunately, I ran into the following install error on macOS (Python 3.10.4). Any thoughts?
Installing collected packages: jdaviz
Running setup.py develop for jdaviz
error: subprocess-exited-with-error
× python setup.py develop did not run successfully.
│ exit code: 1
╰─> [7 lines of output]
running develop
/private/var/folders/93/k31j59sj2493rzfqxc8r5z0r000171/T/pip-build-env-6pu_hgaf/overlay/lib/python3.10/site-packages/setuptools/command/easy_install.py:144: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools.
warnings.warn(
/private/var/folders/93/k31j59sj2493rzfqxc8r5z0r000171/T/pip-build-env-6pu_hgaf/overlay/lib/python3.10/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
warnings.warn(
error: [Errno 2] No such file or directory: '/Users/dnguyen/duydir/gitrepos/jdaviz/envpr1218/share/jupyter/nbconvert/templates/jdaviz-default'
/Users/dnguyen/duydir/gitrepos/jdaviz/envpr1218/src/jdaviz/share/jupyter/nbconvert/templates/jdaviz-default -> /Users/dnguyen/duydir/gitrepos/jdaviz/envpr1218/share/jupyter/nbconvert/templates/jdaviz-default
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
I have no idea where OSX stores the data files. Does this mean anything to you? Is the path wrong?
|
What is the value when you install via the setup command in |
I see a copy of the default jdaviz template in
Isn't the symlink supposed to be linking this? |
When I install from main, it looks like the symlink to
|
Since you can reproduce the error, are you able to run the code in |
Also, why didn't it trigger failure in the OSX CI job? |
Before we go that far, we might want to request someone else to reproduce? (Also considering the OSX job didn't fail?) |
Installs fine for me with OSX and python 3.8.13. |
Sounds like it's just me! Thanks for the check @javerbukh ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's my approval for the Windows side! Thanks for fixing this thorn that has been in my side for a while!
A'ight.... Let's merge.... 🤞 Thanks for the reviews! |
@pllim I actually ran into the same traceback when testing another PR, @duytnguyendtn did you find a fix for it? |
Oh no 😱 Should we revert? |
If @duytnguyendtn hasn't found a fix then maybe. Do you know what the cause of that error was? |
Nope, I never figured out what the problem was. I thought it was a transient because I was able to install a different branch that was rebased on top of this one, and with the unit tests passing and @javerbukh clear, I thought it was just something local to that instance... apparently not |
A question that popped into my head, @javerbukh were there any differences between the test you ran #1218 (comment) and when you ran into the issue in #1218 (comment)? I'm also curious to know if you installed in editable mode both times? |
Reverting did fix it for me so I would vote for that. I must have not tested this in a new conda environment because as soon as I created a new one after this was merged I saw the error. I did install in editable mode both times. |
I confirmed that I can't install in a fresh environment on Mac/Python 3.9 due to this error, I agree with reverting. |
Or opening a bug fix PR if anyone can find the solution quickly. |
I don't have a Mac to test on, so any patch I try would just be wild guessing. If we revert, I can repatch Windows with the my barebone attempt before Duy wanted the Path stuff. |
Thanks. For non-ancient versions of Windows, symlinks work as non-admin as long as you put your computer in "developer mode" (found in the settings panel "Developer settings"). As such, my only request would be to try to use symlinks also on Windows, and only try the copying if for some reason symlinks fail. That makes things much easier for me (I don't get the workaround solution when not needed, and the code doesn't just assume I cannot use symlinks just because I'm on Windows). |
True, I think a solution that tries but has a fallback mechanism is probably a better idea. |
@vidartf and @maartenbreddels , sorry I overlooked your feedback here. I have opened #1282 for follow-up but not sure when I can get back to it. |
Description
This pull request is to improve quality of life for developers that have to develop Jdaviz on Windows.
@maartenbreddels , does this patch look reasonable to you from the voila side?
Fixes #925
Fixes #1213
Checklist for package maintainer(s)
This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.
trivial
label. If @duytnguyendtn okays this, good enough.CHANGES.rst
?