-
Notifications
You must be signed in to change notification settings - Fork 104
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
Error in case conda-lock is started from another drive than the default temporary directory lies on #175
Comments
Can you provide the stack trace please? I don't have ready access to a windows machine with >1 drive on it. |
Deleted original message as it contained the wrong stack trace. |
That stack trace has nothing to do with relative path? |
Sorry. Mixed this with the other issue I filed yesterday. 🙈 C:\Users\Username\Miniconda3\lib\site-packages\setuptools\command\install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
warnings.warn(
Locking dependencies for ['win-64']...
INFO:conda_lock.conda_solver:win-64 using specs ['python >=3.0']
Traceback (most recent call last):
File "C:\Users\Username\Miniconda3\Scripts\conda-lock-script.py", line 9, in <module>
sys.exit(main())
File "C:\Users\Username\Miniconda3\lib\site-packages\click\core.py", line 1137, in __call__
return self.main(*args, **kwargs)
File "C:\Users\Username\Miniconda3\lib\site-packages\click\core.py", line 1062, in main
rv = self.invoke(ctx)
File "C:\Users\Username\Miniconda3\lib\site-packages\click\core.py", line 1668, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "C:\Users\Username\Miniconda3\lib\site-packages\click\core.py", line 1404, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "C:\Users\Username\Miniconda3\lib\site-packages\click\core.py", line 763, in invoke
return __callback(*args, **kwargs)
File "C:\Users\Username\Miniconda3\lib\site-packages\click\decorators.py", line 26, in new_func
return f(get_current_context(), *args, **kwargs)
File "C:\Users\Username\Miniconda3\lib\site-packages\conda_lock\conda_lock.py", line 1166, in lock
lock_func(
File "C:\Users\Username\Miniconda3\lib\site-packages\conda_lock\conda_lock.py", line 936, in run_lock
make_lock_files(
File "C:\Users\Username\Miniconda3\lib\site-packages\conda_lock\conda_lock.py", line 388, in make_lock_files
lock_content = lock_content | create_lockfile_from_spec(
File "C:\Users\Username\Miniconda3\lib\site-packages\conda_lock\conda_lock.py", line 739, in create_lockfile_from_spec
sources=[
File "C:\Users\Username\Miniconda3\lib\site-packages\conda_lock\conda_lock.py", line 740, in <listcomp>
relative_path(lockfile_path.parent, source) for source in spec.sources
File "C:\Users\Username\Miniconda3\lib\site-packages\conda_lock\common.py", line 122, in relative_path
os.path.commonpath((source.resolve(strict=True), target.resolve(strict=True)))
File "C:\Users\Username\Miniconda3\lib\ntpath.py", line 763, in commonpath
raise ValueError("Paths don't have the same drive")
ValueError: Paths don't have the same drive |
riccardoporreca
added a commit
to riccardoporreca/conda-lock
that referenced
this issue
Aug 10, 2022
riccardoporreca
added a commit
to riccardoporreca/conda-lock
that referenced
this issue
Aug 10, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi there
I am using
conda-lock
for a while now and I am experiencing issues since the update to the new major version.Issue
If I run
conda-lock
from a path where the drive is different to the drive from the path of the lockfile I want to generate, the process crashes with aValueError: Paths don't have the same drive
.Environment
conda-lock
version installed:1.0.2=pyhd8ed1ab_0
python
version:3.8.10
System used: Windows 10 Enterprise 20H2
Details
I am using a full build-recipe for
conda-build
, ameta.yaml
file as source.The invocation is equivalent to:
conda lock -p win-64 --file E:\recipe\meta.yaml --lockfile C:\Temp\lock.lock
The issue lies in conda_lock\common.py, line 122, in the function
relative_path
. There is an implicit assumption, that the source and target paths have a common drive.All
1.x.x
versions show this behavior, whereas the last prior version0.13.2
is working as expected.The text was updated successfully, but these errors were encountered: