Try ./sage --pip install pyscipopt
it appears they have a newer version now, 4.4.0.
HTH
Dima
On Friday, February 16, 2024 at 3:48:09 PM UTC Martin R wrote:
> I (urgently) need the scip MILP solver (on 10.3.beta8, Ubuntu 22.04).
>
> sage -i pyscipopt
>
> ends with
>
>
Open for review:
- https://github.com/sagemath/sage/pull/37301 (build/pkgs/pytest*: Change
to standard normal packages)
- https://github.com/sagemath/sage/pull/37300 (build/pkgs/python_build:
Make standard)
On Saturday, February 10, 2024 at 2:18:20 PM UTC-8 Matthias Koeppe wrote:
> We added
Any hope left? If not, which version of sage do I have to downgrade to?
Thank you for all the hints so far!
Martin
martin@toolbox:~/sage-trac$ ./sage -pip install pyscipopt
Collecting pyscipopt
Downloading
PySCIPOpt-4.4.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata
Indeed, #35103 gives a speedup of 50% in the case I'm considering!
Martin
On Friday 16 February 2024 at 20:41:55 UTC+1 Martin R wrote:
> I'm currently checking out https://github.com/sagemath/sage/pull/35103
> and browsing through old issues (there should be one speeding up
> add_constraint,
But you can be lucky with the binary wheel you can get from PyPI. I didn't
test it though, but perhaps it will just work.
On Friday, February 16, 2024 at 4:55:21 PM UTC Matthias Koeppe wrote:
> As noted in
>
On Thursday, February 8, 2024 at 10:16:58 AM UTC-8 Matthias Koeppe wrote:
On Wednesday, February 7, 2024 at 1:11:14 PM UTC-8 Matthias Koeppe wrote:
Let's also use this anniversary as an opportunity to discuss what still
needs improving in our development workflows.
*1. We have a low
On Fri, Feb 16, 2024 at 7:25 PM 'Martin R' via sage-devel <
sage-devel@googlegroups.com> wrote:
> Oh no, sorry, this was a typo!
>
> YES SCIP WORKS!
>
> Only, for some reason this is now slower than GLPK - I'm lost. I'll look
> through the tickets, I think there was a specific one responsible
On Friday, February 16, 2024 at 9:38:16 AM UTC-8 Dima Pasechnik wrote:
It seems you had one vote for, and one against. Is it enough to declare
these packages accepted as standard now?
We haven't counted votes yet.
(Where do you see a vote against the proposal?)
I opened the PRs so that
As noted
in
https://github.com/sagemath/sage/wiki/Sage-10.2-Release-Tour#known-problems-and-workarounds,
our pyscipopt package has not been updated to work with Cython 3 yet.
(Still the same in upstream PySCIPOpt master, as noted
You need an SPD solver - it's a different package, scip_sdp, not pyscipopt.
Try
make scip_sdp
(probably followed up by "make build", just in case)
On 16 February 2024 18:39:52 GMT, 'Martin R' via sage-devel <
sage-devel@googlegroups.com> wrote:
> Any hope left? If not, which version of sage
Oh no, sorry, this was a typo!
YES SCIP WORKS!
Only, for some reason this is now slower than GLPK - I'm lost. I'll look
through the tickets, I think there was a specific one responsible for big
speedups.
Thank you so much for your support!
Martin
On Friday 16 February 2024 at 20:18:42
It seems you had one vote for, and one against. Is it enough to declare
these packages accepted as standard now?
By the way, pytest inclusion already adds 5 standard packages, not one.
On Friday, February 16, 2024 at 5:24:57 PM UTC Matthias Koeppe wrote:
> Open for review:
> -
I'm currently checking out https://github.com/sagemath/sage/pull/35103 and
browsing through old issues (there should be one speeding up
add_constraint, because indeed for the current problem most of the time
(according to %prun) is spent in add_constraint, and I reported and fixed
some of
Hi Nils,
Le vendredi 16 février 2024 à 04:37:28 UTC+1, Nils Bruin a écrit :
On Thursday 15 February 2024 at 17:02:14 UTC-8 Dima Pasechnik wrote:
but that's sphinx (Python), not jupyter.
I see. The page I linked to is from Jupyter{book} which is, despite the
similarity in name, not the jupyter
On Friday, February 16, 2024 at 1:25:13 PM UTC-8 Dima Pasechnik wrote:
>On Friday, February 16, 2024 at 9:38:16 AM UTC-8 Dima Pasechnik wrote:
My vote for is conditional on them remaining pip packages, and that's not
what your PRs do.
I'll count that as 0.
--
You received this message
On Friday, February 16, 2024 at 6:26:32 PM UTC-8 Kwankyu Lee wrote:
By default the package content would be fetched, as pip does,
Not just as pip does, but by actually calling "pip" to contact PyPI.
and that would mean the default configuration for sage would require
internet at install
On Friday, February 16, 2024 at 8:44:06 PM UTC-8 Nathan Dunfield wrote:
Dima mentioned "tox" [1] as an example of a "standard" package that would
benefit from being switched to a "pip" package. The "tox" package is pure
python, so could also made a "wheel" package, which are already allowed
On Friday, February 16, 2024 at 3:57:06 PM UTC-8 Nils Bruin wrote:
As far as I understand, the proposal is to allow sage "packages" to be
closer to more standard python prerequisites by letting them be resolved by
pip packages.
No, we already have such Sage packages: This is just one of the 4
On 16 February 2024 20:05:51 GMT, Matthias Koeppe
wrote:
>On Friday, February 16, 2024 at 9:38:16 AM UTC-8 Dima Pasechnik wrote:
>
>It seems you had one vote for, and one against. Is it enough to declare
>these packages accepted as standard now?
>
>
>We haven't counted votes yet.
>(Where do
By default the package content would be fetched, as pip does,
Not just as pip does, but by actually calling "pip" to contact PyPI.
and that would mean the default configuration for sage would require
internet at install time.
That's right.
Then Dima's proposal implies assuming
On 16 February 2024 23:33:48 GMT, Matthias Koeppe
wrote:
>On Friday, February 16, 2024 at 1:25:13 PM UTC-8 Dima Pasechnik wrote:
>
>>On Friday, February 16, 2024 at 9:38:16 AM UTC-8 Dima Pasechnik wrote:
>My vote for is conditional on them remaining pip packages, and that's not
>what your
Note that posting a proposal here on sage-devel to make the packages
standard followed the policies of our project.
"optional packages stay in that status for at least a year, after which
they can be proposed to be included as standard packages in Sage. For this
a GitHub PR is opened with the
Dima mentioned "tox" [1] as an example of a "standard" package that would
benefit from being switched to a "pip" package. The "tox" package is pure
python, so could also made a "wheel" package, which are already allowed for
standard package, for example [2]. I'm having difficultly
On Monday, February 12, 2024 at 4:05:05 PM UTC-8 Dima Pasechnik wrote:
On Mon, Feb 12, 2024 at 11:52 PM Matthias Koeppe
wrote:
> If there are relevant use cases without internet connectivity (I have no
opinion to offer on this), then the release tarball has exactly the right
contents.
This
As far as I understand, the proposal is to allow sage "packages" to be
closer to more standard python prerequisites by letting them be resolved by
pip packages. By default the package content would be fetched, as pip does,
and that would mean the default configuration for sage would require
25 matches
Mail list logo
