On Wednesday, September 25, 2024 at 7:01:54 PM UTC-7 Michael Orlitzky wrote:
the
version_requirements.txt for the sage distribution should contain the
version requirements for the sage distribution. That's what they're
for
That's right, and that's indeed what the update PR
https://github.com
On 2024-09-25 11:55:36, Matthias Koeppe wrote:
> On Monday, September 23, 2024 at 5:34:26 AM UTC-7 Michael Orlitzky wrote:
>
> On Sun, 2024-09-22 at 20:05 -0700, 'tobia...@gmx.de' via sage-devel
> wrote:
> > Matthias claims these
> > are needed for the system-site-package feature.
>
> --enabl
On Monday, September 23, 2024 at 5:34:26 AM UTC-7 Michael Orlitzky wrote:
On Sun, 2024-09-22 at 20:05 -0700, 'tobia...@gmx.de' via sage-devel
wrote:
> Matthias claims these
> are needed for the system-site-package feature.
--enable-system-site-packages doesn't care about pyproject.toml
No,
Thanks, that's helpful!
On Monday, September 23, 2024 at 8:34:26 PM UTC+8 Michael Orlitzky wrote:
> On Sun, 2024-09-22 at 20:05 -0700, 'tobia...@gmx.de' via sage-devel
> wrote:
> > Michael, to make things short: The discussion is around these changes to
> > the `pyproject.toml` file
> >
> http
On Sun, 2024-09-22 at 20:05 -0700, 'tobia...@gmx.de' via sage-devel
wrote:
> Michael, to make things short: The discussion is around these changes to
> the `pyproject.toml` file
> https://github.com/sagemath/sage/pull/38227/files#diff-0acbedc0b174ebec342997fdca9442a5486917ab04644da866213e97d25436
Michael, to make things short: The discussion is around these changes to
the `pyproject.toml` file
https://github.com/sagemath/sage/pull/38227/files#diff-0acbedc0b174ebec342997fdca9442a5486917ab04644da866213e97d2543604
which he claims harmonize the constraints with scipy (although scipy
actual
On 19 September 2024 03:20:52 BST, Michael Orlitzky
wrote:
>On Wed, 2024-09-18 at 16:23 -0700, Matthias Koeppe wrote:
>>
>> I would appreciate feedback from the developers working on this feature
>> (Dima?, Michael?) regarding how to specify these constraints now that
>> sage-lib defines it
On Wed, 2024-09-18 at 16:23 -0700, Matthias Koeppe wrote:
>
> I would appreciate feedback from the developers working on this feature
> (Dima?, Michael?) regarding how to specify these constraints now that
> sage-lib defines its own constraints in pyproject.toml.
>
> The change is purely syntac
On Monday, September 9, 2024 at 6:08:36 AM UTC-7 tobia...@gmx.de wrote:
The PR does not include any explanation as to why the changes to
pyproject.toml are necessary, nor does it provide any guidance on how to
test them.
Yes, it does not, because it's the same for every package upgrade PR. We
The PR does not include any explanation as to why the changes to
pyproject.toml are necessary, nor does it provide any guidance on how to
test them. I used the standard configure process (now also with the
system-site-packages switch) followed by make, both with and without these
changes, an
On Friday, September 6, 2024 at 1:43:32 AM UTC-7 tobia...@gmx.de wrote:
I've set the PR back to needs work since the version constraints in
pyproject.toml for cython and numpy are not needed in my testing,
definitely not for sage-the-lib but apparently not even for sage-the-distro
(at least I
Moreover, there is actually a very simple way to specify a different
constraint for sage-the-distro: just remove the auto-gen of the
version-requirements file, and provide an own one for sage-the-distro.
That way was discussed in
https://github.com/sagemath/sage/pull/37902#discussion_r174489
On Friday, September 6, 2024 at 3:00:47 PM UTC+9 tobia...@gmx.de wrote:
The cython constraint in scipy is for build-time. Sagelib only cares about
the fact that scipy is installed in the same venv, not how you install or
build it. In fact, pip uses build isolation by default, or you may install
@Kwankyu, replying here to your comments.
The cython constraint in scipy is for build-time. Sagelib only cares about
the fact that scipy is installed in the same venv, not how you install or
build it. In fact, pip uses build isolation by default, or you may install
scipy using the prebuilt whee
No, it is Sage the distro getting in the way of sagelib.
On Sunday, August 25, 2024 at 6:52:40 AM UTC+1 Matthias Koeppe wrote:
> On Friday, August 23, 2024 at 1:21:47 PM UTC-7 tobia...@gmx.de wrote:
>
> Why would one want to specify a more narrow version range?
>
>
> It's not a goal, it's a tradeo
On Friday, August 23, 2024 at 1:21:47 PM UTC-7 tobia...@gmx.de wrote:
Why would one want to specify a more narrow version range?
It's not a goal, it's a tradeoff.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group an
Why would one want to specify a more narrow version range? That would only
impose unnecessary constraints on downstream packaging efforts.
Another example: https://github.com/sagemath/sage/pull/38556
On Thursday, August 22, 2024 at 8:32:02 PM UTC+2 Matthias Koeppe wrote:
> On Thursday, August 2
On Wednesday, August 21, 2024 at 3:35:57 PM UTC-7 Nils Bruin wrote:
I don't think *you* would need to maintain that set. It would just be
something to maintained.
:)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this gr
On Thursday, August 22, 2024 at 2:41:57 AM UTC-7 tobia...@gmx.de wrote:
People interested in maintaining sagelib should only care about the version
constraint in the pyproject.toml file (e.g. if they decide that a new
feature of numpy is needed, then the version constraint of numpy should be
ch
People interested in maintaining sagelib should only care about the version
constraint in the pyproject.toml file (e.g. if they decide that a new
feature of numpy is needed, then the version constraint of numpy should be
changed accordingly). People interested in maintaining sage-the-distro
sho
On Wednesday, August 21, 2024 at 4:58:42 PM UTC-7 Kwankyu Lee wrote:
> The tighter version constraints are needed by the Sage distribution
Then please specify these version constraints in sage distribution and not
in sage-lib (eg by providing a version_constraint.txt file that is
compatible wit
> The tighter version constraints are needed by the Sage distribution
Then please specify these version constraints in sage distribution and not
in sage-lib (eg by providing a version_constraint.txt file that is
compatible with the version constraints of sage-lib and the tighter
constraints s
On Wednesday 21 August 2024 at 15:29:05 UTC-7 Matthias Koeppe wrote:
On Wednesday, August 21, 2024 at 2:12:30 PM UTC-7 tobia...@gmx.de wrote:
> the version constraints of the packages that happen to be build
dependencies of the Sage library (enumerated in
https://github.com/sagemath/sage/blob/d
On Wednesday, August 21, 2024 at 2:12:30 PM UTC-7 tobia...@gmx.de wrote:
> the version constraints of the packages that happen to be build
dependencies of the Sage library (enumerated in
https://github.com/sagemath/sage/blob/develop/bootstrap#L36) are set in
https://github.com/sagemath/sage/blo
> the version constraints of the packages that happen to be build
dependencies of the Sage library (enumerated in
https://github.com/sagemath/sage/blob/develop/bootstrap#L36) are set in
https://github.com/sagemath/sage/blob/develop/src/pyproject.toml#L3
Right (adhering to the standard of moder
Since Tobias Diez's PR https://github.com/sagemath/sage/pull/36982 ("Make
pyproject.toml the source for build dependencies"; TW: PR comments), merged
in Sage 10.4, the version constraints of the packages that happen to be
build dependencies of the Sage library (enumerated in
https://github.com/
I've set the first one to needs work since it changes some versions in the
pyproject.toml (which specifies the depenendies of sagelib). Since the PR
doesn't include any other changes in sagelib, I don't think these stricter
version constraints for sagelib make sense and should be reverted.
On
27 matches
Mail list logo
