Try to resolve issues for x86 Windows #1045
Conversation
Codecov ReportPatch and project coverage have no change.
Additional details and impacted files@@ Coverage Diff @@
## master #1045 +/- ##
=======================================
Coverage 67.30% 67.30%
=======================================
Files 20 20
Lines 2025 2025
=======================================
Hits 1363 1363
Misses 662 662
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
| # and does not have satisified_skip_solve | ||
| Conda.add("numpy") | ||
| else | ||
| Conda.add("numpy"; satisfied_skip_solve=true) |
There was a problem hiding this comment.
Shouldn't Conda.jl just ignore this flag in that case?
There was a problem hiding this comment.
In most cases, I would want Conda.jl to error rather than silenting ignoring the keyword. The caller should either anticipate the error or handle the error.
Here, I'm just trying to maintain backwards compatability for a very specific situation, 32-bit Windows, which upstream conda no longer supports.
There was a problem hiding this comment.
I'm not 100% convinced that an error is the behavior Conda.add users would want.
The satisfied_skip_solve flag in practice mostly seems like an optional hint to speed things up, as it is used here, and it's a bit ugly that callers of Conda.jl will have to know about and implement the 32-bit windows exception themselves.
There was a problem hiding this comment.
The critical feature here is not to speed things up, but rather maintain the current version of numpy if already installed.
@MilesCranmer encountered the original issue when working with a conda-forge recipe. Conda-forge tries to depend on the oldest numpy possible for compatibility, but this was inadvertently upgrading numpy to the latest version. This created a binary package cobbling situation.
--satisfied-skip-solve is an important feature supported by all current releases of miniconda and miniforge. At minimum at warning would be needed if this not succeed. Otherwise, we may be doing something the user did not intend.
Honestly, my preferred solution is to stop supporting conda on 32-bit Windows and Python 2.7 entirely due to lack of upstream support. However, this incompatibility occurred without warning.
There was a problem hiding this comment.
Honestly, my preferred solution is to stop supporting conda on 32-bit Windows and Python 2.7 entirely due to lack of upstream support
I also see this as the best solution.
|
@davidanthoff any thoughts about this? |
|
I'm trying to clarify conda's perspective on 32-bit Windows and why This seems to be where conda-forge's support stopped: Scipy appears to have dropped support since October 2022: |
|
I created an alternative solution at JuliaPy/Conda.jl#246 . There Conda.jl will issue a warning if someone tries to use |
miniforge is no longer available for x86 Windows and does not have satisified solve
Fix JuliaPy/Conda.jl#241 (comment)