Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

On Thursday, 6 July 2023 at 23:25:12 UTC+2 Nils Bruin wrote:

It looks to me proposal 1 still doesn't make it *mandatory* to drop support 
outside of the NEP29-defined version window. It seems to me that it just 
defines when a support-drop PR becomes acceptable to merge, and that such a 
PR would only be issued once someone feels there's a benefit to its merge.

If that interpretation is right, it seems to me that the difference between 
proposal 1 and proposal 2 will only be relevant if there is a PR to drop a 
python version V (outside of the NEP29 window) and there is someone else 
who want to keep support for that version V. With proposal 2 we'd get a 
discussion of the relevant pros and cons. With proposal 1, there'd normally 
not be a discussion at this point: version V is fair game to be dropped. 
There could still be a discussion if someone claims there's an exceptional 
circumstance that warrants deviating from official policy, but that would 
have a much higher bar to clear.


Yes, this interpretation is what I had in mind. 
 

>From the perspective above, Proposal 1 seems more attractive to me than 
Proposal 2, since it avoids extra discussion with what seems a very 
reasonable default policy (the NEP 29 window seems wide enough to me). 


For me, this is the main advantage of having a policy about the drop 
schedule. We can now have a dedicated conversation to thoroughly explore 
the pros and cons, to consider various perspectives, gather feedback, and 
make an informed decision. Once a policy has been established and agreed 
upon, it provides a clear framework that eliminates the need for repetitive 
discussions and debates about dropping specific policies in every PR again. 



-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/56b2148c-7b22-4631-ba7c-2e931ae03bc3n%40googlegroups.com.

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

Thanks David for your suggestions! 

I've now created a wiki page at 
https://github.com/sagemath/sage/wiki/NEP-29:-Python-version-strategy that 
on the one hand clarifies a few questions that were raised before and on 
the other hand summarizes the discussion we had so far. I tried to add all 
points raised as objectively as possible, but could have easily missed some 
arguments and misinterpreted others. So please have a look a the page and 
edit it as you see fit. I propose that major additions or changes to the 
wiki page are first discussed here on the mailing list so that we don't end 
in a edit war.

On Tuesday, 27 June 2023 at 19:30:46 UTC+2 David Roe wrote:

> Thanks for restarting the discussion Tobias.  From my perspective, there 
> are several things that can move this conversation forward.
> 1. More clarity on how NEP-29 will be implemented in Sage.  In particular, 
> that policy just guarantees a particular time frame during which Python 
> *will* be supported, but doesn't describe what happens afterward.  Once 
> the window is passed, is someone (who?) going to proactively update build 
> scripts to prohibit the old version of python?  Or does it just grant 
> permission for people to use features that are not available in the old 
> Python, and merging such a PR will also involve updating the build 
> requirements?
> 2. A wiki page. Currently, the arguments for and against this change are 
> pretty scattered.  Tobias (and Dima), could you create a wiki page where 
> pros and cons are summarized?  Once you do, I would suggest running it by 
> Matthias, since a lot of the arguments against it have come from him.
> 3. A timeline.  I'm going to suggest three weeks for discussion, with 
> voting starting July 18 and ending one week later on July 25 (anywhere on 
> earth).  I know that there have been conversations on and off about this 
> issue for a while, but I think having some time dedicated to focused 
> discussion may help others feel like they have a full grasp of the issue.
> 4. Additional people getting involved in the conversation.  Tobias, Dima 
> and Matthias all clearly feel quite strongly about this issue and have been 
> involved in it for a while.  Other people can hopefully bring some more 
> perspectives, suggesting compromises or giving additional perspectives.  In 
> the end, we *need* other people to vote, so that Tobias, Dima and 
> Matthias can get some resolution on this.
> 5. A moderator.  Several people asked me to moderate last time, and I'll 
> do my best for this discussion.  I'll start with a few requests for 
> everyone involved. 
>  * First, I think multiple short, quick rebuttals are not a good idea in a 
> heated email discussion.  We have three weeks.  Take the time to collect 
> your thoughts and respond to the whole of an argument.  If appropriate, add 
> things to the pros and cons on the wiki page.  Most of all, take the time 
> to read what you've written and think about how it will be received by both 
> the people you're arguing with and the thousands of people subscribed to 
> sage-devel. 
>  * Second, take a step back and think about what you can do to make this 
> environment more welcoming and pleasant for everyone.  I know several 
> people involved have said that the issues we're discussing, and the way 
> we're discussing them, have lessened their desire to contribute to Sage, 
> and I think that would be a tragedy.  All three of you are critical members 
> of this community, and I don't want to lose you.  I'm not going to 
> prescribe anything specific, but I think it would help if everyone can 
> think about ways to show that you value the people involved, even if we 
> have specific technical disagreements.
>  * Third, while work goes forward on a summarizing wiki page, I'd like to 
> hear suggestions from others about how to make the process better.  Feel 
> free to email the list or write to me directly.
>
> We made it through the github discussion, and we can make it through 
> this.  Stay positive.
> David
>
> On Tue, Jun 27, 2023 at 10:14 AM Tobias Diez  wrote:
>
>> Any suggestions on how to move forward now? Should I simply open a new 
>> vote or are there still open questions or a need to discuss certain aspects 
>> of the proposal?
>>
>> On Sunday, 4 June 2023 at 19:49:23 UTC+2 G. M.-S. wrote:
>>
>>>
>>> For the benefit of all of us (including Dima, Matthias and Tobias), 
>>> would it be possible to start afresh, without any reference whatsoever to 
>>> these 3 linked discussions?
>>>
>>> Also, would it be possible for David to act somehow as a "moderator"?
>>>
>>> Best,
>>>
>>> Guillermo
>>>
>>> On Sun, 4 Jun 2023 at 1

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

Any suggestions on how to move forward now? Should I simply open a new vote 
or are there still open questions or a need to discuss certain aspects of 
the proposal?

On Sunday, 4 June 2023 at 19:49:23 UTC+2 G. M.-S. wrote:

>
> For the benefit of all of us (including Dima, Matthias and Tobias), would 
> it be possible to start afresh, without any reference whatsoever to these 3 
> linked discussions?
>
> Also, would it be possible for David to act somehow as a "moderator"?
>
> Best,
>
> Guillermo
>
> On Sun, 4 Jun 2023 at 17:37, Tobias Diez  wrote:
>
>> On Saturday, 3 June 2023 at 19:31:18 UTC+8 Marc Culler wrote:
>>
>> That is what always happens when people try to force a vote before there 
>> has been a discussion of sufficient depth to allow a consensus to form.  
>>
>>
>> To clarify since this point came up before: The discussion about this 
>> topic started over two years ago in 
>> https://github.com/sagemath/sage/issues/30384, then this February 
>> continued on the sage mailing list (
>> https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ) and 
>> in April in the PR https://github.com/sagemath/sage/pull/35403. However, 
>> only Matthias, Dima and me joined the discussion. Since we three couldn't 
>> come to a consensus, I opened the vote in order to get the input from the 
>> broader sage community (following advice from David and William).
>>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/feaeb36f-129b-4c18-9789-6cc97c1556a9n%40googlegroups.com.

Re: [sage-devel] Re: Modularation doctests

[Tobias Diez]

On Wednesday, 14 June 2023 at 05:37:15 UTC+8 Matthias Koeppe wrote:

- Some # optional annotations reduce the barrier for contributors, by 
clearly signaling to developers "it's OK and definitely not your fault if 
you don't understand this doctest". 


To be honest, this sounds like wishful thinking. As a (new) user, reading 
"# optional - sage.symbolic" makes me more think "wtf. what is this? how do 
I install this sage.symbolic thing so that I can run use this example?!" 
then "oh, yes, this test depends on another part of sage, that I have not 
yet encountered, so I don't need to try to understand this example". This 
reading is also more in line with Travis' anecdotal evidence " Furthermore, 
the large amount of optional labels, especially with no actual optional 
packages, is starting to scare some users. I tell them they can ignore it, 
but I feel that is not giving off a good impression. It is even more 
confounding for people who are starting to develop (e.g., the GSoC 
students)."

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4d511798-99dd-4bf4-9855-5af11f8e316en%40googlegroups.com.

Re: [sage-devel] Re: Modularation doctests

[Tobias Diez]

On Wednesday, 14 June 2023 at 05:03:21 UTC+8 Matthias Koeppe wrote:

More specifically, when users of a modularized distribution make their 
first steps to contributing to it, that's already difficult; and we do not 
want to have to tell them "if you want to make this contribution, you first 
have to become a real SageMath user."


Judging from the current people interested in the modularization, it seems 
more likely that a few senior sage devs will work on modularized 
distribution. 
But my question was more: what kind of issues/bugs do you try to prevent by 
modularizing the tests as well?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3860b4ed-1386-4305-b1cd-ad9e2ee46614n%40googlegroups.com.

Re: [sage-devel] Re: Modularation doctests

[Tobias Diez]

On Wednesday, 14 June 2023 at 02:36:16 UTC+8 Matthias Koeppe wrote:

- Modularized distributions must be testable separately!


And why is this a desirable goal? 
Integration tests almost by definition are testing multiple modules/units 
and thus don't fit into this scheme. 
Admittedly, the only multi-package monorepos I know are in the javascript 
world but there people usually don't bother to modularize their tests for 
exactly this reason (e.g. https://github.com/vuejs/vue/tree/main/test). Do 
you know of examples of projects that follow the "Modularized distributions 
must be testable separately!"-mantra? 
 

My thought was that when you declare a new module, you run the doctests of 
that module. They usually break for two reasons:
a) some real dependency was not declared for that module - in this case, 
add the dependency and run the tests again.
b) some doctests require a library that is not a dependency of the original 
module - in this case, add an optional tag to the failing doctest (current 
solution)

My proposal would be in b) to add it the offending import to a whitelist 
("test dependency of module xyz") and then all doctests for module xyz are 
ignoring import errors for these whitelisted dependencies. So in short, 
instead of annotating each doctest you annotate the module.


After you whitelist an import from *M* because there is some valid doctest 
that uses *M* for integration-testing purposes (for example, by testing 
basic linear algebra functionality by running it on an element of an 
algebra defined in *M*), the modularized distribution is no longer guarded 
by its testsuite against modularization regressions that involve the 
whitelisted module.


Sure, this hides issues from libraries that are declared to be test 
dependencies but that actually are/become actual dependencies. But the same 
problem, on a slightly smaller scale, you have with file-wide "optional" 
annotations - and even with line annotations. One way out would be to 
analyze the stack trace and see if the error is thrown in a pure doctest 
code or while running code in module M. 

But I think it would be better to reuse tools (or at least their ideas) 
that were developed exactly to manage and restrict dependencies between 
different layers/modules of an application, such as 
https://github.com/zyskarch/pytestarch, 
https://github.com/seddonym/import-linter, 
https://github.com/jwbargsten/pytest-archon, 
https://github.com/TNG/ArchUnit. All of them define external rules about 
admissible relationships.  

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c18fb2bb-2644-49f2-8ea0-ca1c25642d35n%40googlegroups.com.

Re: [sage-devel] Re: Modularation doctests

[Tobias Diez]

Maybe I'm misunderstanding the purpose of the modularized doctests. Can 
someone explain me what they should test and what not?

My thought was that when you declare a new module, you run the doctests of 
that module. They usually break for two reasons:
a) some real dependency was not declared for that module - in this case, 
add the dependency and run the tests again.
b) some doctests require a library that is not a dependency of the original 
module - in this case, add an optional tag to the failing doctest (current 
solution)

My proposal would be in b) to add it the offending import to a whitelist 
("test dependency of module xyz") and then all doctests for module xyz are 
ignoring import errors for these whitelisted dependencies. So in short, 
instead of annotating each doctest you annotate the module. 

On Tuesday, 13 June 2023 at 23:46:26 UTC+8 Dima Pasechnik wrote:

> On Tue, Jun 13, 2023 at 4:14 PM Tobias Diez  wrote:
> >
> > What about a completely different approach: Instead of annotating the 
> doctests, simply ignore test blocks that fail due to a thrown import error 
> (or missing feature error) of a package that is not installed in the 
> modularized test environment?
>
> How do you see the doctest framework distinguishing "real" import
> errors from the ones caused by modularisation?
>
>
>
> > That might hide some edge cases, but would in total be a less intrusive 
> way to handle things.
> >
> > At the very least, I would propose to hide these optional tags from the 
> generated docs.
> > On Monday, 12 June 2023 at 16:50:11 UTC+8 Dima Pasechnik wrote:
> >>
> >> On Mon, Jun 12, 2023 at 1:35 AM 'Travis Scrimshaw' via sage-devel
> >>  wrote:
> >> >
> >> > Hi Matthias,
> >> >
> >> > Happy to see that you are curious regarding the modularization 
> project, but I don't think it's a good approach to start this discussion 
> with claims that sound authoritative ("nobody will actually maintain", 
> "does not scale", "nearly all end users", etc.) and a policy proposal.
> >> >
> >> >
> >> > Yes, you're right. I do not have any hard analytic data to support 
> what users want and are doing, and that observation is based solely on my 
> years of experience with working with Sage, going to and speaking at 
> SageDays, and convincing people to start using Sage. However, there is 
> clear evidence that the current approach is not scaling by the amount of 
> work that is going in and frequent updates/fixed that is needed to be done. 
> Currently, only you are the one doing this.
> >>
> >> What exactly is not scaling? "Vendor everything" approach abandoned ~9
> >> years ago obviously didn't scale.
> >> I think we're not unvendoring things aggressively enough, and that's
> >> what we quarrel with Matthias about.
> >>
> >> I'm about to start a round of discussions here to lead to a vote to
> >> remove vendored gcc and gfortran.
> >> We also should be getting rid of Sage-nonspecific things such as
> >> vendored Python (with the needed dependencies such as openssl),
> >> and vendored Jupyter and its huge slew of its dependencies (for the
> >> latter Matthias is on board, I think).
> >>
> >> It's also not correct that modularisation is currently only done by
> >> Matthias. E.g. most recently I worked on unvendoring of Maxima.
> >> I worked on doing some abstract classes for parts of sage.coding, I
> >> worked on spinning out prime counting stuff into a separate
> >> pip-installable module (that was in 2021, though), etc.
> >>
> >> The interdependecies of parts of Sage library on each other are
> >> decreasing, and this is certainly a big deal in terms of
> >> updating/fixing
> >> things. (Not importing from sage.all in the library is a big deal).
> >>
> >> Dima
> >>
> >>
> >> Some of that is the lack of discussion (which I would like to have
> >> seen given the large scale nature of this change, which is implicitly
> >> setting policy by default). You can disagree with my conclusions and
> >> proposal, but I want to actually talk about that rather than having
> >> dismissive comments. Can you provide any specific counterpoints and
> >> your expectations? What you posted on the other thread does not
> >> address any of these.
> >> >
> >> > Best,
> >> > Travis
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google 
> Groups &qu

Re: [sage-devel] Re: Modularation doctests

[Tobias Diez]

What about a completely different approach: Instead of annotating the 
doctests, simply ignore test blocks that fail due to a thrown import error 
(or missing feature error) of a package that is not installed in the 
modularized test environment? That might hide some edge cases, but would in 
total be a less intrusive way to handle things.

At the very least, I would propose to hide these optional tags from the 
generated docs.
On Monday, 12 June 2023 at 16:50:11 UTC+8 Dima Pasechnik wrote:

> On Mon, Jun 12, 2023 at 1:35 AM 'Travis Scrimshaw' via sage-devel
>  wrote:
> >
> > Hi Matthias,
> >
> > Happy to see that you are curious regarding the modularization project, 
> but I don't think it's a good approach to start this discussion with claims 
> that sound authoritative ("nobody will actually maintain", "does not 
> scale", "nearly all end users", etc.) and a policy proposal.
> >
> >
> > Yes, you're right. I do not have any hard analytic data to support what 
> users want and are doing, and that observation is based solely on my years 
> of experience with working with Sage, going to and speaking at SageDays, 
> and convincing people to start using Sage. However, there is clear evidence 
> that the current approach is not scaling by the amount of work that is 
> going in and frequent updates/fixed that is needed to be done. Currently, 
> only you are the one doing this.
>
> What exactly is not scaling? "Vendor everything" approach abandoned ~9
> years ago obviously didn't scale.
> I think we're not unvendoring things aggressively enough, and that's
> what we quarrel with Matthias about.
>
> I'm about to start a round of discussions here to lead to a vote to
> remove vendored gcc and gfortran.
> We also should be getting rid of Sage-nonspecific things such as
> vendored Python (with the needed dependencies such as openssl),
> and vendored Jupyter and its huge slew of its dependencies (for the
> latter Matthias is on board, I think).
>
> It's also not correct that modularisation is currently only done by
> Matthias. E.g. most recently I worked on unvendoring of Maxima.
> I worked on doing some abstract classes for parts of sage.coding, I
> worked on spinning out prime counting stuff into a separate
> pip-installable module (that was in 2021, though), etc.
>
> The interdependecies of parts of Sage library on each other are
> decreasing, and this is certainly a big deal in terms of
> updating/fixing
> things. (Not importing from sage.all in the library is a big deal).
>
> Dima
>
>
> Some of that is the lack of discussion (which I would like to have
> seen given the large scale nature of this change, which is implicitly
> setting policy by default). You can disagree with my conclusions and
> proposal, but I want to actually talk about that rather than having
> dismissive comments. Can you provide any specific counterpoints and
> your expectations? What you posted on the other thread does not
> address any of these.
> >
> > Best,
> > Travis
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/84fbc2ed-00c8-4ca6-8aa7-d4c74e8c2455n%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/cc125172-2413-4416-b871-f4fdc606a4c7n%40googlegroups.com.

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

On Saturday, 3 June 2023 at 19:31:18 UTC+8 Marc Culler wrote:

That is what always happens when people try to force a vote before there 
has been a discussion of sufficient depth to allow a consensus to form.  


To clarify since this point came up before: The discussion about this topic 
started over two years ago in 
https://github.com/sagemath/sage/issues/30384, then this February continued 
on the sage mailing list 
(https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ) and 
in April in the PR https://github.com/sagemath/sage/pull/35403. However, 
only Matthias, Dima and me joined the discussion. Since we three couldn't 
come to a consensus, I opened the vote in order to get the input from the 
broader sage community (following advice from David and William).

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2c1be32b-904b-4186-85bc-e2268dfba25bn%40googlegroups.com.

Re: [sage-devel] Develop Sage inside GitHub Codespaces and/or other "cloud" options?

[Tobias Diez]

I used github codespaces for sage development for some until since I only 
had a weak laptop with me. It worked quite well, actually better than 
gitpod (mainly due to better vscode integration). But you can easily try it 
out yourself. Just go to 
https://github.com/codespaces/new?hide_repo_select=true=develop=597660615
 
(or use Code > Codespaces from https://github.com/sagemath/sage if the 
direct link is not working) and create a codespace.  You may need to select 
the 4 core machine type, otherwise leave the defaults (develop branch and 
conda devcontainer). We provide prebuilds, so it should only take a min or 
so until you have a dev environment with fully compiled sage. 

On Saturday, 3 June 2023 at 22:40:15 UTC+8 William Stein wrote:

> On Sat, Jun 3, 2023 at 7:13 AM Jing Guo  wrote:
>
>> Thank you, Dima. I just learned that CoCalc also provides dev environment 
>> setup...
>>
>
> I can also give you a significant free upgrade on cocalc if you want to 
> use it for sage dev. 
>
>
>> I guess I will try GitPod first then.
>>
>> 在2023年6月3日星期六 UTC+2 14:26:01 写道：
>>
>>> On Sat, Jun 3, 2023 at 1:19 PM Jing Guo  wrote: 
>>> > 
>>> > I have not. I am exploring different options and weighing the 
>>> pros-and-cons. 
>>>
>>> Another option is cocalc.com - although you'd rather pay for 
>>> subscription, to allow development environments. 
>>> Apart from this, I am only aware of GitPod and Codespaces. 
>>> Needless to say, you can also set up a sufficently big VM on a cloud 
>>> service and use it, but most probably you'd need to pay, 
>>> as Sage is resource-hungry. 
>>>
>>>
>>> > 
>>> > 在2023年6月3日星期六 UTC+2 14:01:00 写道： 
>>> >> 
>>> >> On Sat, Jun 3, 2023 at 12:16 PM Jing Guo  wrote: 
>>> >> > 
>>> >> > Hello everyone, 
>>> >> > 
>>> >> > Last year, I developed Sage inside Linux VM (Debian, to be 
>>> specific) on my old Macbook Pro, so the compiling time was not really good, 
>>> or was not what it could have been. 
>>> >> > 
>>> >> > Recently, I learn that there exist some services like GitHub's 
>>> Codespaces, which seems to provide develop-and-build environments on their 
>>> own machines(?). I was wondering that if anyone have had some experience 
>>> with these services. If so, do you have any recommendations for 
>>> alternatives other than the GitHub one? Or would you say that the GitHub 
>>> one is good enough? (Sage documentation seems to suggest GitPod) 
>>> >> 
>>> >> Have you tried GitPod? 
>>> >> 
>>> >> > 
>>> >> > Thank you for your time. 
>>> >> > 
>>> >> > Jing 
>>> >> > 
>>> >> > -- 
>>> >> > You received this message because you are subscribed to the Google 
>>> Groups "sage-devel" group. 
>>> >> > To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to sage-devel+...@googlegroups.com. 
>>> >> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/686c07aa-a4d5-4f50-88cf-0e30f0e95278n%40googlegroups.com.
>>>  
>>>
>>> > 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups "sage-devel" group. 
>>> > To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to sage-devel+...@googlegroups.com. 
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/60475ea1-a782-4c54-a3dc-a8d1dacc8b53n%40googlegroups.com.
>>>  
>>>
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/6d2df1b1--4820-8817-12a37327f6d7n%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
> -- William Stein
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/74197697-dbfc-4f43-8969-936f525d83b8n%40googlegroups.com.

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

On Wednesday, 31 May 2023 at 03:00:53 UTC+8 Nils Bruin wrote:

On Tuesday, 30 May 2023 at 11:13:27 UTC-7 tobia...@gmx.de wrote:

that we normally drop support for older versions right after this support 
window (i.e. also adapt the drop schedule 
https://numpy.org/neps/nep-0029-deprecation_policy.html#drop-schedule). 
I've formulated an improved formulation for this policy at 
https://github.com/sagemath/sage/pull/35403#issuecomment-1566110884 which 
should hopefully clarify this point.
 
(Dropping support means increasing `python_requires` and removing github 
tests for this old version, i.e. similar to 
https://github.com/sagemath/sage/pull/35404 which is modeled on the PR 
drooping Python 3.7.)


Formulated like this it would seem to me we could needlessly reduce the 
platforms that sage builds on: this suggests that the "drop Python 3.*" PR 
would get merged simply because it's time: in theory we could end up with a 
release where the sole commit is the dropping of support (in practice 
development is way too active for this). I would expect that such a PR 
would only get merged as a dependency of some other PR (that makes a fix, 
enhancement, or upgrades some other component).


Yes, in theory that could happen. Since its real work that someone has to 
put in to create a "drop Python 3.*" PR, I suspect that this persons needs 
to see a clear benefit before opening the PR. So I suspect that one first 
notices "oh shit, this doesn't work on Python x" and then proceeds to 
create a drop PR if its already past the NEP29 time window. But I'm happy 
to encode this practice in the policy. Do you have a suggestion for a 
formulation?
 


Having a policy that makes clear when such a drop PR is acceptable as a 
prerequisite for merging could save work and discussion. Numpy's schedule 
looks like a reasonable candidate for that.


That was exactly my intention. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d66e2ed7-b45c-430d-85e1-5789396b416en%40googlegroups.com.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

I can also point at the already existing possibility  to use Conda's Python 
packages on a Conda-based install.


This mode of installation (
https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental)
 
bypasses the Sage distribution entirely and installs the Sage library 
separately using pip.


And there were problems with this mode of installation for Python 3.8 that 
no one had the time to fix. On the other hand, it works perfectly well and 
is tested via github actions for all NEP29-supported Python versions. So 
this serves as a prime example of how supporting multiple Python versions 
can be challenging.
 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1f8621ee-288e-4aee-8637-fe583d650375n%40googlegroups.com.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

 
> a) Sage has a dual role as a library ("project") and as a distribution. 
NEP 29 was designed for projects, and not for software distributions. 

What problems do you see that come from sage having aspects of a software 
distribution? 

"Sage-the-distribution" allows us to reduce the inconvenience for end-users 
when their (system) python version is too old. In this case, sage 
automatically installs a newer Python. So I would argue that NEP29 is 
actually a great fit for a hybrid application like sage since the 
distribution aspect reduces some of the disadvantages that come with the 
quicker drop schedule of NEP29.



On Saturday, 27 May 2023 at 19:17:08 UTC+8 Emmanuel Charpentier wrote:

> I'd like to stress one important point already made : dropping support for 
> old/antique/paleontologic versions of Python lightens the maintainance 
> workload of the *small* team of Sage developpers.
>
> Given the size and the state of this team, this point should *not* be 
> taken lightly...
>
> I'd also like to hear on this point from our release manager : would this 
> proposed policy change have an influence on his workload ?
>
> HTH,
>
> Le vendredi 26 mai 2023 à 20:54:22 UTC+2, Michael Orlitzky a écrit :
>
>> On Fri, 2023-05-26 at 18:15 +0100, Oscar Benjamin wrote: 
>> > 
>> > What is wrong with Sage just saying that an older version of an 
>> > operating system only works with an older version of Sage? 
>>
>> Matthias alluded to this when he mentioned that we only have one 
>> release branch of sage. Our version numbers are not really meaningful, 
>> and bug fixes and features are released simultaneously. So the only way 
>> to get fixes for critical bugs is to upgrade, but the upgrades come 
>> with new features, and those new features can have new requirements. 
>>
>> That said, I still share your sentiment when there is a good reason (a 
>> term best left undefined) to break compatibility. 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7dc08cf1-e29a-4547-941a-e25544d025c7n%40googlegroups.com.

[sage-devel] Re: Follow NEP 29: Recommended Python version

[Tobias Diez]

> Since we depend on numpy, sage-the-library inherits NEP 29. 

Correct. In practice, we waited for the numpy release that drops a certain 
python version and then dropped that version in tandem with the upgrade of 
numpy. Thus, there was about one release cycle between the drop schedule of 
NEP 29 and the actual drop happening in sage. Formally adopting NEP29 would 
allow us to drop older version a little bit faster (i.e. without needing 
for the numpy release).

> library code or the distribution 

At the moment they have the same minimum Python version, right? 
Sage-the-distro installs a newer version if the system version doesn't fit 
the minimum version of sage-the-library. It is not the plan of this 
proposal to change this behavior (but +1 for using conda in this context). 
Did I understand your question correctly?

On Saturday, 27 May 2023 at 19:02:27 UTC+8 Volker Braun wrote:

> NEP 29 just defines the minimum supported Python version, having a longer 
> support window is equally NEP 29 compatible. 
>
> Since we depend on numpy, sage-the-library inherits NEP 29. There isn't 
> really anything to vote on here.
>
> As far as sage-the-distribution goes, we should tie the support window to 
> popular distros. Ideally by liberally calling "conda install python" 
> whenever the distro python is too old.
>
> Its unclear to me if this or the vote thread is about the library code or 
> the distribution...
>
>
> On Saturday, February 25, 2023 at 4:10:07 AM UTC+1 Tobias Diez wrote:
>
>> Hi all, 
>>
>> I propose to follow the NumPy enhancement proposal 29: "Recommend Python 
>> and Numpy version support as a community policy standard" available at: 
>> https://numpy.org/neps/nep-0029-deprecation_policy.html
>>
>> In essence it specifies when it's okay to drop support for old Python 
>> version. Namely, a release should support "all minor versions of Python 
>> released 42 months prior to the project, and at minimum the two latest 
>> minor versions. ". In particular, this means:
>> - On Apr 14, 2023 drop support for Python 3.8 (initially released on Oct 
>> 14, 2019) 
>> - On Apr 05, 2024 drop support for Python 3.9 (initially released on Oct 
>> 05, 2020)
>>
>> The main idea of NEP 29 is to have a community-wide standard to prevent 
>> issues with e.g. dependencies dropping support for older Python versions to 
>> early. It is followed by many scientific packages such as Scipy, 
>> Matplotlib, and IPython, among others. Sage itself is also roughly 
>> following it (based on the past drops, e.g. Python 3.7 support was dropped 
>> 9 months ago and NEP recommends Dec 26, 2021). But as far as I'm aware 
>> there is not yet a clear policy for when to drop support for older versions.
>>
>> Of course, the dates in the NEP 29 are only a guideline and not set in 
>> stone, e.g. you don't want to drop support at the end of the release cycle 
>> just because the NEP says so. But for example, Sage 10 will be most likely 
>> released after Apr 14 2023, so we can now already drop support for Python 
>> 3.8.
>>
>> Relevant issue: https://github.com/sagemath/sage/issues/30384
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4fce4f84-bc6d-4503-91cb-60e176116e9dn%40googlegroups.com.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

> I have the impression that NEP 29 tried to very 
rigidly define end of life by a specific timeline with no flexibility 
for the potential that the official Python release timelines are not 
rigid and fixed in stone forever 

The PR linked above mentions quite often that they do take 
variations/changes of the Python release schedule into account. For 
example, NEP 29 writes " support at least all minor versions of Python 
introduced and released in the prior 42 months *from the anticipated 
release date* with a minimum of 2 minor versions of Python". With a rigid 
schedule, this is a unnecessary duplication - but the "at least two minor 
versions" is there to prevent the worst case scenario where python releases 
are delayed by a few years and no python version would be supported 
otherwise. But yes, naturally there are some included expectations about 
the Python release schedule included in NEP 29 and it would probably be 
revised if Python changes its schedule. Conversely, NEP 29 is adapted by so 
many libraries that Python itself includes it in discussions about its 
release schedule (e.g. 
https://peps.python.org/pep-0605/#implications-for-the-proposed-scientific-python-ecosystem-support-period)

On Saturday, 27 May 2023 at 00:56:12 UTC+8 Tobias Diez wrote:

> Here is the PR that introduced NEP 29: 
> https://github.com/numpy/numpy/pull/14086. The main discussion happened 
> in person at scipy 2019 and in webcalls. But a lot of the points raised 
> here are answered in this PR.
>
> For example, the point about Linux LTS / Python EOL is addressed by one of 
> the writers of NEP 29 as follows (
> https://github.com/numpy/numpy/pull/14086#issuecomment-516661140)
> " 
>
> Conversely, I am not sure of a real world example where a user must have:
>
>- 4 year old version of Python
>- just-released version of numpy / Matplotilb / scikit-learn [add sage 
>here]
>
> If you are making the choice to stay on an old version of Python (which 
> there are good reasons to do!) then why would you not *also* make the 
> conservative choice to stay on the contemporaneous version of the scipy 
> stack?
> "
>
> The point that "NEP is about libraries and not downstream applications" is 
> also not valid since this clearly was part of the discussion back then. For 
> example, one of the core maintainers of jupyter and ipython writes 
> https://github.com/numpy/numpy/pull/14086#issuecomment-516904953
> " There is also the same catch 22 than dropping python 2; downstream was 
> not dropping because upstream was still supporting Python 2, and upstream 
> was still supporting Python 2 because downstream was relying on it."
> In other words, if all downstream applications would have a more 
> conservative policy, then naturally also numpy etc would need to adapt. NEP 
> 29 is about homogenizing the supported Python version in the scientific 
> python community. This is also very clearly written in the first line of 
> the NEP: "recommends that *all projects *across the Scientific Python 
> ecosystem adopt a common “time window-based” policy for support of Python 
> and NumPy versions" (emphasize mine). Its "all projects", not "all upstream 
> libraries". So unless someone wants to argue that sage is not part of the 
> scientific python ecosystem, we are directly addressed.
>
> By the way, what happened to the "please let the discussion go somewhere 
> else"? Should I restart the voting in a new thread?
> On Friday, 26 May 2023 at 23:10:52 UTC+8 William Stein wrote:
>
>> Hi, 
>>
>> To help with people who want to make an informed decision, is there 
>> any public discussion of the original NEP 29 proposal? 
>>
>> The only thing I could find was this post from Sebastian Berg, where he 
>> says at 
>>
>>
>> https://mail.python.org/pipermail/numpy-discussion/2019-October/080128.html 
>>
>> "We propose formally accepting the NumPy enhancement proposal 29... If 
>> there are no objections within a week it may be accepted.". 
>> There's no public voting or anything, and there's exactly one quick 
>> random response of "yes" in the thread. 
>>
>> In the actual NEP 29 proposal 
>> https://numpy.org/neps/nep-0029-deprecation_policy.html there is a 
>> section labeled "Discussion" and it is empty. 
>> I would love to read about the discussions for/against NEP 29 from 
>> when they decided on it in the first place! 
>>
>> There are follow up discussions, just like this one, by other 
>> projects, e.g., for sympy here: 
>> https://github.com/sympy/sympy/issues/21884, which 
>> is still not decided, and has been under regul

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

e's a simple rationale:
> >
> > I. This proposed policy change does not solve any problem. There are no 
> problems whatsoever with how we have managed the support of Python versions 
> since 2020 (when it became possible to use system Python instead of only 
> the Python from our SPKG.)
> >
> > II. The proposed policy change creates new problems. Following this 
> policy would force us to drop support for a particular Python version at 
> times when it would be harmful for our project. Specifically, right now it 
> would *force* us to drop support for Python 3.8 and hence for using the 
> default Python on Ubuntu Linux 20.04 (an LTS release, with "End of Standard 
> Support" April 2025 and "End Of Life" April 2030. It is the very point of 
> LTS releases to provide a stable software environment; so, yes, Python 3.8 
> is fully supported, and if Python 3.8.x had bugs relevant for Sage, we 
> would know about it because we are testing.
> >
> > III. Our existing practice is to carefully consider and weigh various 
> factors that are relevant for the Sage project, rather than following a 
> fixed schedule that is set by an external, largely separate community. I 
> briefly explained what we do in 
> https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/x3qOdPB5BQAJ; but 
> I'll expand here on some important factors:
> >
> > a) Sage has a dual role as a library ("project") and as a distribution. 
> NEP 29 was designed for projects, and not for software distributions.
> >
> > b) In Sage, we only have one line of releases. Hence users who want any 
> bug fixes need to use our latest version. In contrast, just like Python 
> itself, many other projects have at least two separate branches: A branch 
> on which the cutting edge development takes place (new features etc.), and 
> a branch from which maintenance updates are made. For example, NumPy 
> removed support of Python 3.8 in their development branch earlier this 
> year; but this in preparation for the 1.25 release expected this summer. 
> NumPy continued to make maintenance releases on the 1.24 branch (
> https://github.com/numpy/numpy/releases), and by policy, these 
> maintenance upgrades never drop the support of a previously supported 
> version.
> >
> > c) NEP29 was designed for and is in use by a part of the scientific 
> Python community, to address the need to be able to use features of new 
> Python versions and features of NumPy/SciPy faster. This is important for 
> many projects that have NumPy/SciPy as their dependencies.
> >
> > d) In contrast, our uses of NumPy/SciPy in the Sage library are very 
> basic and dating back by about a decade; with the exception of the optional 
> use of a recent SciPy feature (the high-performance optimization solver 
> HiGHS, see 
> https://github.com/sagemath/sage/wiki/Sage-10.0-Release-Tour#linear-programming-and-extensions),
>  
> which motivated our quick upgrade to the current SciPy version in Sage. And 
> as another example, also our use of matplotlib in the library dates back by 
> a decade or more; we regularly have to update when new matplotlib versions 
> come out that make API changes, but we haven't picked up any new features 
> in a very long time.
> >
> > e) Yes, synchronization between projects matters for maintainability. 
> But Sage is downstream of lots of Python packages; before we can offer 
> support for a new version of Python, we often have to wait until all or 
> most of our dependencies provide support for that new version. For example, 
> some projects are actively working on support for the Python 3.12 release 
> expected this early Fall; but for us, this is not actionable because we 
> have to wait for critical dependencies; see 
> https://github.com/sagemath/sage/issues/34788 . Likewise, it is not 
> useful for us to drop support for an old version before there is a clear 
> benefit for us, brought for example by important upgrades that have dropped 
> support already.
> >
> >
> > (As suggested by Tobias, any discussion of my explanations above is best 
> sent to the 
> https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ 
> thread.)
> >
> >
> > On Friday, May 26, 2023 at 3:12:16 AM UTC-7 Tobias Diez wrote:
> >>
> >> Dear Sage developers,
> >>
> >> the NumPy enhancement proposal 29: "Recommend Python and Numpy version 
> support as a community policy standard" (available at 
> https://numpy.org/neps/nep-0029-deprecation_policy.html) specifies when 
> it's okay to drop support for old Python version.
> >>
> >> Namely, a release should support "all minor versions of Python

[sage-devel] VOTE: Follow NEP 29: Recommended Python version

[Tobias Diez]

Dear Sage developers,

the NumPy enhancement proposal 29: "Recommend Python and Numpy version 
support as a community policy standard" (available at 
https://numpy.org/neps/nep-0029-deprecation_policy.html) specifies when 
it's okay to drop support for old Python version. 

Namely, a release should support "all minor versions of Python released 42 
months prior to the project, and at minimum the two latest minor versions. 
". In particular, this means:
- Currently, Sage should support > 3.8.
- On Apr 05, 2024 we should drop support for Python 3.9 (initially released 
on Oct 05, 2020)

Based on previous discussions on this topic 
(https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ, 
https://github.com/sagemath/sage/issues/30384, 
https://github.com/sagemath/sage/pull/35403), I'm calling for a vote on 
adapting the Python version support of NEP 29 in Sage. Voting ends at the 
7th June,  AoE. Please use this thread only for sending votes, to make it 
easier to count them afterward; and use the thread 
https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ for 
discussion.

*Summary *of the points brought forward in the discussions linked above
1. The current practice in Sage is to evaluate whether to increase the 
minimum version of Python supported at the beginning of each release cycle. 
With regard to such a practice, the NEP 29 documents remarks "As there is 
no objective threshold to when the minimum version should be dropped, it is 
easy for these version support discussions to devolve into bike shedding 

 
and acrimony." Sadly, an example of this can be found in the current 
discussion of dropping Python 3.8 support in 
https://github.com/sagemath/sage/pull/35404 with emotions running so high 
that sage-abuse had to step in. Adopting a version policy would prevent 
such discussions. On the other hand, by following a given policy, we would 
loose some flexibility.
2. The main idea of NEP 29 is to have a community-wide standard. It is 
followed by many scientific packages such as Scipy, Matplotlib, IPython, 
Jupyter, Pandas, scikit, astropy, cuda, cirq, jax, pytorch among others. The 
adoption of NEP 29 will harmonize Sage's deprecation policy with these 
other major libraries. 
3. The NEP 29 drop schedule is much faster than the EOL schedule of Python 
itself. Python 3.8 is supported until 2024-10, but NEP 29 already drops it 
2023-04. However, adhering to the EOL schedule would prevent us to updating 
these packages that follow NEP 29.
4. The NEP 29 schedule is about one release cycle faster than the previous 
drops (e.g. Python 3.7 support was dropped in Sage 9.7 while according to 
NEP 29 it would have been Sage 9.6).
5. The faster drop schedule will free developer resources (less systems to 
test) and potentially increase developer productivity as it allows us to 
use newer language features.
6. The faster drop schedule might be inconvenient for users who rely on 
older Python versions. To some extend this is remedied by our python 
install package, and relatively straightforward upgrade paths on most 
system. One should also note that users relying on other scientific python 
packages are likely forced to upgrade anyway, since these other packages 
likely follow NEP 29.
7. The faster drop schedule would force users to upgrade to newer Python 
versions and thereby profit from fewer bugs and security issues. It is 
however questionable if Sage should play this educator role.
8. One of the main goals of NEP 29 is to improve downstream project 
planning by having a community-wide standard. This is currently not very 
relevant for us as Sage is currently upstream of nothing except for some 
user packages. With the modularization effort, this may change in the 
future.
9. There are not many other documented policies. As said above, most 
scientific python projects follow NEP 29. Most projects in web development 
(e.g flask) seem to drop a version once it reaches EOL. Machine learning 
projects follow a similar EOL policy (e.g. tensorflow) or roughly follow 
NEP 29 (scikit-learn). Some end-user applications have even stricter 
version constraints then NEP 29 (e.g. home-assistant only supports the two 
latest minor releases).

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d321fa7e-47d0-40ed-9468-e090b11cb86fn%40googlegroups.com.

Re: [sage-devel] weird commits on top of develop

[Tobias Diez]

The branch protection rules don't allow to make an exception for a single 
person (the release manager). What can be configured though is that all 
pushes to develop (from everybody, including admins) have to go through a 
PR. This would mean that the merge and release commits also has to go 
through a PR. Maybe this is a good idea anyway, since then the github ci 
checks that everything is okay (relative to the setup tests) and would 
prevent the need for these "fix the ci" commits.

On Monday, 27 February 2023 at 05:54:29 UTC+8 Matthias Koeppe wrote:

> Branch protection is on, but currently admins can bypass it. This can be 
> tightened in the config here if so desired:
> https://github.com/sagemath/sage/settings/branch_protection_rules/33965567
>
>
> On Sunday, February 26, 2023 at 12:36:42 PM UTC-8 Volker Braun wrote:
>
>> I agree that we should turn on branch protection, it is rather easy to 
>> accidentally push to develop.
>>
>> Its also not ok to push what you think is a CI fix without it going to 
>> review, we had some irregularities to support the github transition but 
>> that is over now. 
>>
>>
>>
>> On Sunday, February 26, 2023 at 11:19:24 AM UTC+1 Vincent Delecroix wrote:
>>
>>> I do not understand why develop isn't protected against anybody but 
>>> the release manager pushes. 
>>>
>>> On Sun, 26 Feb 2023 at 11:16, Dima Pasechnik  wrote: 
>>> > 
>>> > it was a mistake on my side - I thought develop branch was broken, but 
>>> it was not. 
>>> > 
>>> > On Sun, 26 Feb 2023, 10:13 Vincent Delecroix, <20100.d...@gmail.com> 
>>> wrote: 
>>> >> 
>>> >> Hello, 
>>> >> 
>>> >> Why do we have commits on top of develop after the release commits? 
>>> Namely 
>>> >> 
>>> >> commit 52a81cbd161ef4d5895325657c88a68590ea1d3b 
>>> >> Author: Dima Pasechnik  
>>> >> Date: Fri Feb 24 21:15:42 2023 + 
>>> >> 
>>> >> Revert "add missing # optional - gap3" 
>>> >> 
>>> >> This reverts commit c017a6a3d68f0aca8cb63ceba52fe451a64881a3. 
>>> >> 
>>> >> commit c017a6a3d68f0aca8cb63ceba52fe451a64881a3 
>>> >> Author: Dima Pasechnik  
>>> >> Date: Fri Feb 24 11:57:32 2023 + 
>>> >> 
>>> >> add missing # optional - gap3 
>>> >> 
>>> >> to let CI pass 
>>> >> 
>>> >> Best 
>>> >> Vincent 
>>> >> 
>>> >> -- 
>>> >> You received this message because you are subscribed to the Google 
>>> Groups "sage-devel" group. 
>>> >> To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to sage-devel+...@googlegroups.com. 
>>> >> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/CAGEwAAkF50jNxVth6io%2BCErWu9mWFW4L2D%2BERqQVcNf7aPjp1A%40mail.gmail.com.
>>>  
>>>
>>> > 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups "sage-devel" group. 
>>> > To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to sage-devel+...@googlegroups.com. 
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/CAAWYfq0XTpPcxuKuE11ChKpx0jcAjsxGRVsrD%2BLDeQO-X4RxnQ%40mail.gmail.com.
>>>  
>>>
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1796d13d-3abe-4bb3-a7b6-fd35fac65810n%40googlegroups.com.

[sage-devel] Follow NEP 29: Recommended Python version

[Tobias Diez]

 Hi all, 

I propose to follow the NumPy enhancement proposal 29: "Recommend Python 
and Numpy version support as a community policy standard" available at: 
https://numpy.org/neps/nep-0029-deprecation_policy.html

In essence it specifies when it's okay to drop support for old Python 
version. Namely, a release should support "all minor versions of Python 
released 42 months prior to the project, and at minimum the two latest 
minor versions. ". In particular, this means:
- On Apr 14, 2023 drop support for Python 3.8 (initially released on Oct 14, 
2019) 
- On Apr 05, 2024 drop support for Python 3.9 (initially released on Oct 05, 
2020)

The main idea of NEP 29 is to have a community-wide standard to prevent 
issues with e.g. dependencies dropping support for older Python versions to 
early. It is followed by many scientific packages such as Scipy, 
Matplotlib, and IPython, among others. Sage itself is also roughly 
following it (based on the past drops, e.g. Python 3.7 support was dropped 
9 months ago and NEP recommends Dec 26, 2021). But as far as I'm aware 
there is not yet a clear policy for when to drop support for older versions.

Of course, the dates in the NEP 29 are only a guideline and not set in 
stone, e.g. you don't want to drop support at the end of the release cycle 
just because the NEP says so. But for example, Sage 10 will be most likely 
released after Apr 14 2023, so we can now already drop support for Python 
3.8.

Relevant issue: https://github.com/sagemath/sage/issues/30384

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e3aa64c0-c61a-4ae3-b753-d918804d0805n%40googlegroups.com.

[sage-devel] Non-profit github account

[Tobias Diez]

Github provides a free teams account for (registered) non-profit orgs. 
There is not a huge difference between the free and the teams account (see 
https://github.com/pricing), especially if we don't use private repos. 
However, prebuilds for Github Codespaces can only be enabled for orgs on 
the Teams plan and this is a nice feature as it would allow people to start 
developing sage in a matter of seconds without setting up a local 
environment. 

For this reason, I wanted to ask if someone could start the application for 
the non-profit Teams plan at https://support.github.com/contact/nonprofit. 
My understanding is that SageMath is not an officially registered 
non-profit org, so this application might not be successful. But at 
https://socialimpact.github.com/ one finds "Not a nonprofit? Submit a 
request for your social good project, and we’ll let you know if you qualify 
for a discount." so there is still hope (we are a social good project, 
right? ;-) ). I can also the application, but maybe someone with a deeper 
understanding of the official status of the sagemath org can provide more 
details.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/841f5658-68a7-4b08-9531-8b87399f0216n%40googlegroups.com.

Re: [sage-devel] Github Discussions

[Tobias Diez]

What about moving this sage-devel mailing list to github discussions? I 
think this is orthogonal to handling the user support via gh discussions.

Btw, you one can customize the notifications to only include/exclude 
discussions: 
https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications#configuring-your-watch-settings-for-an-individual-repository

On Thursday, 9 February 2023 at 10:54:51 UTC+8 kcrisman wrote:

> Personal feeling is that a lot of people who have Sage *questions* are 
> less likely to have GH accounts.  I mean, some will.  But a lot won't.  So 
> the friction for them would be similar to the other options - though 
> sage-support maybe less so, as probably more people have Google accounts. 
>  And for what it's worth, recent questions on ask.sagemath seem to still be 
> getting decent traction - though we do have a fragmentation problem that is 
> not likely to disperse no matter what solution we use, because in the end 
> people ask questions about Sage coming from everything from high school 
> users to developers.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e0ad812c-63b0-4394-bf4d-bd08106ddecfn%40googlegroups.com.

Re: [sage-devel] Merging fix for github CI

[Tobias Diez]

You need to use upstream (the official sage repo) instead of origin (your 
fork) to fetch the PR: git fetch upstream 
pull/PULL-REQUEST-ID/head:LOCAL-BRANCH-NAME see 
https://github.com/sagemath/trac-to-github/blob/master/docs/Migration-Trac-to-Github.md#for-reviewing-a-change

If you don't have an "update branch" button, then this means you currently 
don't have write access to the sagemath repo and thus cannot modify PRs (we 
still have to sort out all the permission stuff...). I've clicked the 
button for you now.
 
On Wednesday, 8 February 2023 at 19:01:01 UTC+8 Martin R wrote:

> Interesting, because the PR page is still the same.for me.
>
> I feel so stupid, I'm sorry, I need more help.  In particular, I get:
>
> martin@convex63:~/sage$ LANG=en git fetch origin pull/34974/head  
> fatal: couldn't find remote ref pull/34974/head
>
> (Note that this is not *my* pull request, but somebody else's, who is 
> trying to provide a fix for my (easy) ticket, I want to serve as reviewer.  
> I do *not* want to give positive review to the pull request as it is 
> currently.)
>
> I cloned sage according to "Otherwise, start afresh:" at 
> https://github.com/sagemath/trac-to-github/blob/master/docs/Migration-Trac-to-Github.md
>
> I have:
>
> martin@convex63:~/sage$ git remote -v 
> origin  g...@github.com:mantepse/sage.git (fetch) 
> origin  g...@github.com:mantepse/sage.git (push) 
> trachttps://github.com/sagemath/sagetrac-mirror.git (fetch) 
> trachttps://github.com/sagemath/sagetrac-mirror.git (push) 
> upstreamg...@github.com:sagemath/sage.git (fetch) 
> upstreamg...@github.com:sagemath/sage.git (push)
>
> It is not clear to me what I should be doing to
>
> 1.) try the PR
> 2.) enable the linting, building and doc checks.
>
> Please excuse me :-(
>
> Martin
>
> On Wednesday, 8 February 2023 at 11:37:57 UTC+1 dim...@gmail.com wrote:
>
>> On Wed, Feb 8, 2023 at 10:23 AM 'Martin R' via sage-devel 
>>  wrote: 
>> > 
>> > Since the failures are 
>> > 
>> > sage -t --random-seed=130442615951932153031063473470828108756 
>> sage/schemes/elliptic_curves/ell_curve_isogeny.py # 1 doctest failed 
>> > sage -t --random-seed=130442615951932153031063473470828108756 
>> sage/schemes/elliptic_curves/ell_number_field.py # 2 doctests failed 
>> > 
>> > I assume that the PR is based on an old branch, but the PR page does 
>> not contain "update branch".. It does contain "Merging is blocked", but I 
>> don't really understand what this means. 
>>
>> I just did 
>> git fetch origin pull/34974/head 
>> (with origin being the main new GitHub repo for sage) 
>> to see the git log, and magically on 
>> https://github.com/sagemath/sage/pull/34974 
>> there is now 
>>
>> This branch is out-of-date with the base branch 
>> Merge the latest changes from develop into this branch. 
>>
>> and "Update branch" button just above "Merge is blocked" 
>> (which is just a reflection of the fact that develop branch is 
>> protected, you can't push/merge there (I can, as Admin, though)) 
>>
>> Perhaps that was due to the base branch being so old, that no branch 
>> info on that was computed by GitHub ahead of my fetch. 
>>
>>
>>
>> > 
>> > Martin 
>> > On Wednesday, 8 February 2023 at 10:42:24 UTC+1 dim...@gmail.com 
>> wrote: 
>> >> 
>> >> 
>> >> 
>> >> On Wed, 8 Feb 2023, 08:41 'Martin R' via sage-devel, <
>> sage-...@googlegroups.com> wrote: 
>> >>> 
>> >>> I cannot see any "update branch" button on 
>> https://github.com/sagemath/sage/pull/34974 
>> >>> 
>> >>> Where should I look for it? 
>> >> 
>> >> 
>> >> This button is somewhere near the ticket status at the bottom - if 
>> your base is indeed outdated. 
>> >> 
>> >> But check the commits on the branch. 
>> >> I went on the merging spree last night, to gauge the performance of 
>> the CI a bit. 
>> >> 
>> >>> 
>> >>> Martin 
>> >>> 
>> >>> On Wednesday, 8 February 2023 at 00:32:49 UTC+1 dim...@gmail.com 
>> wrote: 
>>  
>>  On Tue, Feb 7, 2023 at 10:42 PM David Roe  
>> wrote: 
>>  > 
>>  > Thanks Dima! 
>>  > 
>>  > There is now an "Update branch" button at the bottom of each PR, 
>> which you can press if you're the originator of the PR and it will merge in 
>> develop 
>>  
>>  (there is an option to rebase rather than to merge on this button - 
>>  although automatic rebase is less guaranteed) 
>>  
>>  I was impatient and I pressed this for a number of PRs myself :-) 
>>  I see now CI passing for quite a number, looks quite good. 
>>  
>>  Dima 
>>  
>>  > David 
>>  > 
>>  > On Tue, Feb 7, 2023 at 8:18 PM Dima Pasechnik  
>> wrote: 
>>  >> 
>>  >> done 
>>  >> 
>>  >> On Tue, Feb 7, 2023 at 6:54 PM John Cremona  
>> wrote: 
>>  >> > 
>>  >> > Strong yes from me. 
>>  >> > 
>>  >> > #34987 concerns a 3-line doctest where only the first has a 
>> #long time tag thought the other lines depend on the first having been run, 
>> so causes a failure when tested 

Re: [sage-devel] Question about real names in the new github workflow

[Tobias Diez]

Wouldn't it be easier to automate (and more respectful to the privacy 
concerns of contributors) to simply link to the github handle/profile?

On Wednesday, 8 February 2023 at 04:51:30 UTC+8 Matthias Koeppe wrote:

> We have collected these mappings in 
> https://github.com/sagemath/website/blob/master/conf/contributors.xml, 
> which would be easy to read from in a GH Actions workflow.
>
>
>
> On Tuesday, February 7, 2023 at 8:58:51 AM UTC-8 Dima Pasechnik wrote:
>
>>
>>
>> On Tue, 7 Feb 2023, 11:33 'Martin R' via sage-devel, <
>> sage-...@googlegroups.com> wrote:
>>
>>> Has there been already a decision how we incorporate the real name 
>>> "Author" and "Reviewer" fields?
>>>
>>> I think that this is rather important, because not making a decision 
>>> will probably also be a decision - there are already several new pull 
>>> requests.
>>>
>>> Personally, I am very much for continuing the tradition of real names, 
>>> but it is not clear to me whether there is a mapping between user name and 
>>> real name on github anyway, which would make this information redundant.  
>>> Is the "Name" in a github account optional?
>>>
>>
>> yes, names are optional on GitHub, so we will need some kind of mapping 
>> to keep.
>>
>> We can also get names of authors and reviewers in the PR description 
>> enforced by a bot.
>> We can also require this info to be put in a special textfile to be 
>> collected at merging time and put into a changelog file.
>> (amending changelog directly is prone to conflicts).
>>  
>>
>>
>>> Martin
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "sage-devel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to sage-devel+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/c2c8654a-0511-43a7-a7e5-66c6e687178an%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e90c1072-9ff3-4392-9c4a-a133c22de288n%40googlegroups.com.

[sage-devel] Re: about cypari2 development amd maintenance on github

[Tobias Diez]

One can use the branch protection rule to restrict who can merge PRs into 
the protected branch: 
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#restrict-who-can-push-to-matching-branches

But of course this only takes care of the technical side. It can of course 
still happen that someone oversees an issue in a PR or that the standard of 
"good code" differ slightly. I guess for this only communication, writing 
documentation and, for the base level, linter help.

On Friday, 11 November 2022 at 11:48:52 UTC+1 vdelecroix wrote:

> Dear all,
>
> I am one of the maintainer of cypari2. Contrarily to Jeroen and Luca
> who left, I am not a number theorist and not a specialist of PARI/GP.
> I took over the maintainance responsability because it felt like a
> good thing for the math community and because PARI development happens
> in a nearby lab and Bill Allombert is constantly helping.
>
> I had other tasks to do these days and was not very pro-active. Some
> members of sagemath, though not registered as sagemath/cypari2 admin,
> decided to start integrating merge requests even though these merge
> requests were not adequate (eg version bump inside a merge request and
> code that depended on a development branch of cysignals). It took me a
> lot of headache to rewrite git history and end up with a clean
> release. I am very frustrated that it took me a full day rather than
> an hour to finalize this release. Moreover, the forced push to the
> master branch is not nice to the contributors of cypari2.
>
> Do you have suggestion on how such things could be avoided with
> cypari2 being on github under the sagemath group?
>
> Best regards,
> Vincent
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d889a3aa-07c5-4f23-8fca-47d6d1dfec0en%40googlegroups.com.

[sage-devel] Re: Help wanted: Issue and PR templates, replacement for ticket dependencies

[Tobias Diez]

You can have advanced more advanced controls like checkboxes or 
dropdownboxes in issue forms, see 
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema#dropdown.
 
Some of this is used in 
https://github.com/sagemath/sage-gh-templates-sandbox/pull/1.

On Monday, 17 October 2022 at 19:50:45 UTC+2 seb@gmail.com wrote:

> I think there are two steps to be taken. The first step is to define a 
> suitable template to collect all the important information in the header of 
> issues and PRs that we are used to from the Trac ticket box.
>
> In terms of dependencies between PRs, this will map what we are used to. 
> The second step according to discussion 4477 
>  will go beyond that. 
> So this has a lower priority. But it will be nice to have!
>
> As for the first step, I would suggest having templates that mimic the 
> Trac ticket box for example:
>
> $ cat .github/ISSUE_TEMPLATE/trac_ticket_like_issue.md
> ---
> name: Issue according to Trac ticket
> about: This template provides a similar structure to a Trac ticket
> title: "[Short Description] "
> labels: 'p:major'
> milestone: 'sage-9.8'
> assignees: ''
>
> ---
>
> # Checklist for creating a Trac ticket-like issue
>
> - [ ] I have read 
> [README.md](https://github.com/sagemath/sage/blob/develop/README.md)
> - [ ] I have read [the Troubleshooting section in the Installation 
> Guide](https://doc.sagemath.org/html/en/installation/troubles.html)
> - [ ] I have checked that this will not be a duplicate
> - [ ] I have chosen a label from the Type 
> listt:bugt:enhancementt:task
> - [ ] I have chosen a label from the Priority 
> listp:blockerp:criticalp:majorp:minorp:trivial
> - [ ] I have chosen a label from the Component 
> listc:algebrac:algebraic 
> geometryc:...
>
> # Information that used to be in the Trac ticket box
>
> |||||
> |-|-|-|-|
> |Authors||Reviewers||
> |Keywords||Report upstream||
> |Dependencies||Stopgaps||
>
> # Description of the issue
>
> This would also help with the change of habits. But it seems that this 
> cannot be done only through appropriate templates. As far as I’ve seen, 
> there’s no way to have radio buttons or select lists with GitHub markdown, 
> even with plain HTML. Therefore, we would also need to implement 
> corresponding GitHub actions (see also my comment on issue 8 
>  in the trac-to-github 
> repo ). These would be 
> needed to synchronize between corresponding Trac and GitHub features, too.
>
> If there is interest to have such a template I can volunteer to produce a 
> first draft (but maybe this will take a while since I have only short 
> time-slots and I’m inexperienced with these GitHub tools).
> ​
> Matthias Koeppe schrieb am Montag, 10. Oktober 2022 um 20:42:28 UTC+2:
>
>> As discussed previously, Issue and PR templates on GitHub can provide a 
>> replacement for the Trac ticket box. See 
>> ​https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository
>>  
>> 
>>
>> https://github.com/sagemath/sage-gh-templates-sandbox is open for trying 
>> out possible designs for these templates. A first draft of one template:
>> ​https://github.com/sagemath/sage-gh-templates-sandbox/issues/new/choose 
>> 
>>
>>
>> Related: Help is needed with choosing a good replacement for our Trac 
>> ticket dependencies. As suggested in 
>> ​https://github.com/sagemath/publications/pull/142#issuecomment-1259001501 
>> 
>>  and ​https://groups.google.com/g/sage-devel/c/hX6ojxlNwOU/m/dup_Ywu1BQAJ 
>> , 
>> we should add to ​the transition guide 
>> 
>>  how 
>> to model Trac's ticket dependencies in GitHub PRs. See 
>> ​https://github.com/orgs/community/discussions/4477 
>>  for solutions.
>>
>>
>> This is part of https://trac.sagemath.org/ticket/30363
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [sage-devel] Re: Democratic issue: rushing decisions

[Tobias Diez]

I just had another look at the voting thread, where most votes were voiced 
in the first two days, and the almost-slient discussion thread, where 
mostly a few practical aspects of the migrations were discussed. From this, 
I don't get the impression that the most voters felt they needed more time 
to think or discuss their decision.

In general, I would keep the voting system simple. The migration to github 
was one particular vote, but for example the voting on the doc styles was 
held without much of a prior discussion and on a shorter deadline.

So maybe something simple as the following?
"Small votes:" Have to have a github issue that is at least one week old, 
don't require a discussion on the mailing list and the voting period cannot 
be shorter than 4 days.
"Big votes": Require a discussion thread on the mailing list that is at 
least one week old and the voting period cannot be shorter than 1.5 weeks.
Upon the public request of a single member of the mailing list, every 
"small vote" can be upgraded to a "big vote". In this case, all previously 
handed-in votes are invalid and a discussion thread has to be opened.

On Friday, 7 October 2022 at 17:43:02 UTC+2 John H Palmieri wrote:

> I apologize for being indirect. I was responding to Dima's sentence, "... 
> the delay was requested by an individual ..." which implies that there was 
> just one person requesting the delay. I was pointing out, apparently too 
> indirectly, that more than one person had requested a delay, and perhaps 
> not everyone who requested a delay was guilty, in Dima's view, of some 
> transgression.
>
> In short: Dima, cut it out with the straw men ("straw man: an 
> intentionally misrepresented proposition that is set up because it is 
> easier to defeat than an opponent's real argument").
>
>
> On Friday, October 7, 2022 at 3:45:27 AM UTC-7 dim...@gmail.com wrote:
>
>> On Fri, Oct 7, 2022 at 12:19 AM Kwankyu Lee  wrote: 
>> > 
>> > 
>> > 
>> > On Friday, October 7, 2022 at 7:05:38 AM UTC+9 John H Palmieri wrote: 
>> >> 
>> >> Dima, presumably you're not talking about me, although I proposed that 
>> "we start a vote around October 1". 
>> > 
>> > 
>> > I guess he means: https://trac.sagemath.org/ticket/33725#comment:26 
>>
>> yes, that's exactly what I meant. 
>>
>> Dima 
>>
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "sage-devel" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to sage-devel+...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/be5e2daa-6e2d-4437-bc3a-a8bf38f5a5c6n%40googlegroups.com.
>>  
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/51c38e6c-7ecc-4034-b69d-9e52cb274228n%40googlegroups.com.

Re: [sage-devel] Re: DISCUSS: move Sage development to Github

[Tobias Diez]

Github as their own open archive program 
(https://archiveprogram.github.com/) and works together with known software 
/ archive websites. In particular, the code itself is archived via the 
EU-funded Software Heritage foundation and issue/PR metadata for all public 
repos are in GHTorrent / GHArchive. Thus, in the unlikely situation of 
massive policy changes of GH including a complete removal/block of their 
API, the data is still there and the community will probably develop 
migration tools to whatever platform will become popular then.

In addition, one can download a "migration archive" from github which 
should include all data 
(https://docs.github.com/en/enterprise-server@3.6/admin/user-management/migrating-data-to-and-from-your-enterprise/exporting-migration-data-from-githubcom#generating-a-migration-archive)
 
or use one of the third-party solutions that keep backups per repo 
(https://github.com/marketplace?category=backup-utilities=sort%3Apopularity-desc==).

On Friday, 30 September 2022 at 10:21:15 UTC+2 dim...@gmail.com wrote:

> On Fri, Sep 30, 2022 at 8:59 AM Marc Mezzarobba  
> wrote:
> >
> > John H Palmieri wrote:
> > > You would think that this would be a solved problem: others in the
> > > open source community must have be in the practice of backing up their
> > > GitHub info.
> >
> > The following tools seem fairly complete:
> >
> > - https://github-backup.branchable.com/ (but I'm getting timeouts with
> > it),
> >
> > - https://github.com/josegonzalez/python-github-backup (not tested).
> >
> > IMO we should at the very least have something like that running before
> > making the switch. We should also refrain from using features of github
> > not supported by our backup tool.
>
> While migrating to github, we can get json records for each issue we
> created to replace tickets.
> (they are complete records, everything may be recreated from them)
>
> Then we can set up a GitHub actions to produce such jsons for
> created/updated issues and PRs,
> see e.g. 
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment
>
> I think this is more robust than running tools which make global copies.
> (These updated jsons need to be be stored somewhere)
>
> Dima
>
>
>
> >
> > --
> > Marc
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/th67k9%246eq%241%40ciao.gmane.io
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6553f91a-5d75-498e-9e60-ef3577364ae8n%40googlegroups.com.

Re: [sage-devel] DISCUSS: move Sage development to Github

[Tobias Diez]

Okay, fair enough! Then it's a bit more work to get tickets into PRs (for 
devs) but maybe its a good idea to start with a clean slate.

On Tuesday, 27 September 2022 at 22:31:57 UTC+2 dim...@gmail.com wrote:

>
>
> On Tue, 27 Sep 2022, 21:12 Tobias Diez,  wrote:
>
>> Just to make sure we are talking about the same thing. Imagine a 
>> currently open ticket with a linked branch. How is this going to be 
>> migrated? My assumption has been that this will create a PR from 
>> sagemath/sagetrac-mirror/branch into sagemath/sage.
>>
>
> No, there will be an issue on sagemath/sage, no PR. There will be a link 
> to a branch on sagetrac-mirror (which will be readonly). 
>
> To proceed, just push this branch to your personal fork of sagemath/sage 
> and make a PR from there.
> At this point it becomes a usual github workflow.
>
>
>> If thats indeed the plan (which I find is a good plan), then there are 
>> the following issues:
>> - sagetrac-mirror is not a fork of sage, thus it might not be possible to 
>> create a PR from it (at leas from the web interface its not possible, not 
>> sure about the API)
>> - sagetrac-mirror cannot be archived otherwise it will be readonly (this 
>> is taken care of my Matthias recent edit to the migration wiki page)
>> - devs might not have the permission to push to sagetrac-mirror 
>> (currently there is a branch protection rule in place that prevents any 
>> direct commits, but even if that's removed I'm not sure if everyone can 
>> just push to it)
>>
>
> all this is avoided if done as I described above 
>
> Dima
>
>
>> On Tuesday, 27 September 2022 at 15:29:35 UTC+2 dim...@gmail.com wrote:
>>
>>>
>>>
>>> On Tue, 27 Sep 2022, 14:08 Tobias Diez,  wrote:
>>>
>>>> Yes, the target repo of these PRs will be the (new) sagemath/sage, but 
>>>> the source will be sagemath/sagetrac-mirror, right? 
>>>
>>>
>>>
>>> Hmm, I might have missed something - what is the need to have 2 repos 
>>> here, if 1 is sufficient?
>>>
>>> Any fork of sagemath/sage may be a source of a PR, not only 
>>> sagetrac-mirror
>>>
>>>
>>> So in order to update the pull request one needs to push the changes to 
>>>> sagemath/sagetrac-mirror (it is not possible to update a PR by pushing to 
>>>> /refs/pull/xyz, because this is readonly). Thus, if sagetrac-mirror is 
>>>> archived (and thus readonly), the only way to work on existing 
>>>> tickets/branches would be to checkout the existing branch (from either 
>>>> sagetrac-mirror or sage/refs/pull), make changes, push to a new fork, 
>>>> create a new PR, close the old PR (essentially the workflow 
>>>> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally#modifying-an-inactive-pull-request-locally
>>>> ).
>>>>
>>>> On Tuesday, 27 September 2022 at 13:59:45 UTC+2 dim...@gmail.com wrote:
>>>>
>>>>> On Tue, Sep 27, 2022 at 11:29 AM Tobias Diez  
>>>>> wrote: 
>>>>> > 
>>>>> > One more question: The current plan is to use the sagetrac-mirror 
>>>>> repo as the base for creating PRs but also to archived it. However, if 
>>>>> I'm 
>>>>> not mistaken, that makes all branches in sagetrac-mirror readonly and 
>>>>> thus 
>>>>> one cannot continue working on existing PRs by pushing to the 
>>>>> corresponding 
>>>>> branch in sagetrac-mirror. 
>>>>>
>>>>> IMHO the plan is to create new PRs in sagemath/sage, not in 
>>>>> sagemath/sagetrac-mirror 
>>>>> There won't be "existing" PRs, only issues, pointing to branches on 
>>>>> sagetrac-mirror 
>>>>>
>>>>>
>>>>>
>>>>> > On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com 
>>>>> wrote: 
>>>>> >> 
>>>>> >> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 
>>>>> UTC+2: 
>>>>> >>> 
>>>>> >>> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 
>>>>> wrote: 
>>>>> >>>> 
>>>>> >>>> Is it possible to choose the issue numbers in GH when making a 
>>>>> migration? Then, setting a redirect of the form "
>>>>> https://t

Re: [sage-devel] DISCUSS: move Sage development to Github

[Tobias Diez]

Just to make sure we are talking about the same thing. Imagine a currently 
open ticket with a linked branch. How is this going to be migrated? My 
assumption has been that this will create a PR from 
sagemath/sagetrac-mirror/branch into sagemath/sage.

If thats indeed the plan (which I find is a good plan), then there are the 
following issues:
- sagetrac-mirror is not a fork of sage, thus it might not be possible to 
create a PR from it (at leas from the web interface its not possible, not 
sure about the API)
- sagetrac-mirror cannot be archived otherwise it will be readonly (this is 
taken care of my Matthias recent edit to the migration wiki page)
- devs might not have the permission to push to sagetrac-mirror (currently 
there is a branch protection rule in place that prevents any direct 
commits, but even if that's removed I'm not sure if everyone can just push 
to it)

On Tuesday, 27 September 2022 at 15:29:35 UTC+2 dim...@gmail.com wrote:

>
>
> On Tue, 27 Sep 2022, 14:08 Tobias Diez,  wrote:
>
>> Yes, the target repo of these PRs will be the (new) sagemath/sage, but 
>> the source will be sagemath/sagetrac-mirror, right? 
>
>
>
> Hmm, I might have missed something - what is the need to have 2 repos 
> here, if 1 is sufficient?
>
> Any fork of sagemath/sage may be a source of a PR, not only sagetrac-mirror
>
>
> So in order to update the pull request one needs to push the changes to 
>> sagemath/sagetrac-mirror (it is not possible to update a PR by pushing to 
>> /refs/pull/xyz, because this is readonly). Thus, if sagetrac-mirror is 
>> archived (and thus readonly), the only way to work on existing 
>> tickets/branches would be to checkout the existing branch (from either 
>> sagetrac-mirror or sage/refs/pull), make changes, push to a new fork, 
>> create a new PR, close the old PR (essentially the workflow 
>> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally#modifying-an-inactive-pull-request-locally
>> ).
>>
>> On Tuesday, 27 September 2022 at 13:59:45 UTC+2 dim...@gmail.com wrote:
>>
>>> On Tue, Sep 27, 2022 at 11:29 AM Tobias Diez  
>>> wrote: 
>>> > 
>>> > One more question: The current plan is to use the sagetrac-mirror repo 
>>> as the base for creating PRs but also to archived it. However, if I'm not 
>>> mistaken, that makes all branches in sagetrac-mirror readonly and thus one 
>>> cannot continue working on existing PRs by pushing to the corresponding 
>>> branch in sagetrac-mirror. 
>>>
>>> IMHO the plan is to create new PRs in sagemath/sage, not in 
>>> sagemath/sagetrac-mirror 
>>> There won't be "existing" PRs, only issues, pointing to branches on 
>>> sagetrac-mirror 
>>>
>>>
>>>
>>> > On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com 
>>> wrote: 
>>> >> 
>>> >> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 
>>> UTC+2: 
>>> >>> 
>>> >>> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 wrote: 
>>> >>>> 
>>> >>>> Is it possible to choose the issue numbers in GH when making a 
>>> migration? Then, setting a redirect of the form "
>>> https://trac.sagemath.org/ticket/$TICKET_NUMBER -> 
>>> https://github.com/sagemath/sage/issues/$TICKET_NUMBER; will make the 
>>> lion's share of the links still relevant. 
>>> >>> 
>>> >>> 
>>> >>> Yes, to map it like this is the plan. 
>>> >>> 
>>> >>>> 
>>> >>>> This does not preserve fragments like "#comment:7", which is useful 
>>> in long ticket discussions. 
>>> >>> 
>>> >>> 
>>> >>> Thanks, I've opened 
>>> https://github.com/sagemath/trac-to-github/issues/7 for this. 
>>> >> 
>>> >> Don’t we need an issue for the first point, as well? The example #26 
>>> corresponds to #34110 which is not easy to recover from the migrated 
>>> information. 
>>> >> 
>>> >> Furthermore, it isn’t still clear to me how dependencies between PRs 
>>> will be visible (like in the Trac dependencies field). In the above example 
>>> you have to recover this from the history of commit messages (which may not 
>>> be clear enough in general). Shouldn’t the migration put something into the 
>>> header fields milestone, assignees, …, as well (if possible)? How will 
>&g

Re: [sage-devel] DISCUSS: move Sage development to Github

[Tobias Diez]

Yes, the target repo of these PRs will be the (new) sagemath/sage, but the 
source will be sagemath/sagetrac-mirror, right? So in order to update the 
pull request one needs to push the changes to sagemath/sagetrac-mirror (it 
is not possible to update a PR by pushing to /refs/pull/xyz, because this 
is readonly). Thus, if sagetrac-mirror is archived (and thus readonly), the 
only way to work on existing tickets/branches would be to checkout the 
existing branch (from either sagetrac-mirror or sage/refs/pull), make 
changes, push to a new fork, create a new PR, close the old PR (essentially 
the workflow 
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally#modifying-an-inactive-pull-request-locally).

On Tuesday, 27 September 2022 at 13:59:45 UTC+2 dim...@gmail.com wrote:

> On Tue, Sep 27, 2022 at 11:29 AM Tobias Diez  wrote:
> >
> > One more question: The current plan is to use the sagetrac-mirror repo 
> as the base for creating PRs but also to archived it. However, if I'm not 
> mistaken, that makes all branches in sagetrac-mirror readonly and thus one 
> cannot continue working on existing PRs by pushing to the corresponding 
> branch in sagetrac-mirror.
>
> IMHO the plan is to create new PRs in sagemath/sage, not in
> sagemath/sagetrac-mirror
> There won't be "existing" PRs, only issues, pointing to branches on
> sagetrac-mirror
>
>
>
> > On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com wrote:
> >>
> >> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 
> UTC+2:
> >>>
> >>> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 wrote:
> >>>>
> >>>> Is it possible to choose the issue numbers in GH when making a 
> migration? Then, setting a redirect of the form "
> https://trac.sagemath.org/ticket/$TICKET_NUMBER -> 
> https://github.com/sagemath/sage/issues/$TICKET_NUMBER; will make the 
> lion's share of the links still relevant.
> >>>
> >>>
> >>> Yes, to map it like this is the plan.
> >>>
> >>>>
> >>>> This does not preserve fragments like "#comment:7", which is useful 
> in long ticket discussions.
> >>>
> >>>
> >>> Thanks, I've opened 
> https://github.com/sagemath/trac-to-github/issues/7 for this.
> >>
> >> Don’t we need an issue for the first point, as well? The example #26 
> corresponds to #34110 which is not easy to recover from the migrated 
> information.
> >>
> >> Furthermore, it isn’t still clear to me how dependencies between PRs 
> will be visible (like in the Trac dependencies field). In the above example 
> you have to recover this from the history of commit messages (which may not 
> be clear enough in general). Shouldn’t the migration put something into the 
> header fields milestone, assignees, …, as well (if possible)? How will 
> authors and reviewers be visible?
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/d815783e-fd5c-4aa3-ab27-7024b18b299dn%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6df40198-0d1a-45f4-ac1f-2bee6e07d313n%40googlegroups.com.

Re: [sage-devel] DISCUSS: move Sage development to Github

[Tobias Diez]

One more question: The current plan is to use the sagetrac-mirror repo as 
the base for creating PRs but also to archived it. However, if I'm not 
mistaken, that makes all branches in sagetrac-mirror readonly and thus one 
cannot continue working on existing PRs by pushing to the corresponding 
branch in sagetrac-mirror.
On Tuesday, 27 September 2022 at 10:02:06 UTC+2 seb@gmail.com wrote:

> Matthias Koeppe schrieb am Samstag, 24. September 2022 um 19:09:46 UTC+2:
>
> On Saturday, September 24, 2022 at 9:27:46 AM UTC-7 mathzeta2 wrote:
>>
>>> Is it possible to choose the issue numbers in GH when making a 
>>> migration? Then, setting a redirect of the form "
>>> https://trac.sagemath.org/ticket/$TICKET_NUMBER -> 
>>> https://github.com/sagemath/sage/issues/$TICKET_NUMBER; will make the 
>>> lion's share of the links still relevant.
>>>
>>
>> Yes, to map it like this is the plan.
>>  
>>
>>> This does not preserve fragments like "#comment:7", which is useful in 
>>> long ticket discussions.
>>>
>>
>> Thanks, I've opened https://github.com/sagemath/trac-to-github/issues/7 
>> for this.
>>
> Don’t we need an issue for the first point, as well? The example #26 
>  corresponds to #34110 
>  which is not easy to recover 
> from the migrated information.
>
> Furthermore, it isn’t still clear to me how dependencies between PRs will 
> be visible (like in the Trac dependencies field). In the above example you 
> have to recover this from the history of commit messages (which may not be 
> clear enough in general). Shouldn’t the migration put something into the 
> header fields milestone, assignees, …, as well (if possible)? How will 
> authors and reviewers be visible?
> ​
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d815783e-fd5c-4aa3-ab27-7024b18b299dn%40googlegroups.com.

Re: [sage-devel] DISCUSS: move Sage development to Github

[Tobias Diez]

2. Convert all tickets to Issues in a new repo. (This preserves the ticket 
> numbers as Issue numbers.)
>

Would it make sense to convert tickets with branches directly to 
pull-requests? Since most of them probably already contain quite a bit of 
discussion about the implementation, which you would like to have as a easy 
reference if you would review the PR later. 
 

> 4. Replace sagemath/sage by the new repo.
>

 If you rename a repo (in our case sage -> sage-old), then github adds 
redirects for issues etc in sage to sage_old. So it should be 
double-checked that you can later indeed add a new repo with the name 
sage.  

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6418ac37-a858-447a-be9f-f7d7f4da9461n%40googlegroups.com.

Re: [sage-devel] VOTE: move Sage development to Github

[Tobias Diez]

+1 for Github

On Thursday, 22 September 2022 at 14:19:57 UTC+2 Jonathan wrote:

> +1 for Github
>
> On Thursday, September 22, 2022 at 5:06:02 AM UTC-5 antoine@gmail.com 
> wrote:
>
>> +1 for Github
>>
>> Le jeudi 22 septembre 2022 à 11:38:17 UTC+2, chris wuthrich a écrit :
>>
>>>
>>> 0(No real preference and too little understanding of the matter, but 
>>> very happy that we have a meaningful vote on things like this.)
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c3f97fcd-b046-47e3-9b93-ec766ffe7527n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Tobias Diez]

I think we need also another branch "merge-queue" which serves as the 
target for pull requests, with branch protection rules linear history, 
require positive review and checks.

Also "Release Manager @vbraun merges positively reviewed tickets into his 
branch https://github.com/vbraun/sage; should then be replaced by  "Release 
Manager @vbraun merges positively reviewed tickets into the branch 
merge-queue". You cannot really "merge" pull requests against one repo into 
another one. 

Moreover, I propose to realize "To make a beta or stable release, Release 
Manager merges (fast-forward) his branch into the develop branch and 
creates a tag" by a pull-request from "merge-queue" into "develop". This PR 
could then trigger the corresponding github action checks that should pass 
before a beta is released.  

On Wednesday, 14 September 2022 at 07:50:48 UTC+2 Matthias Koeppe wrote:

> On Tuesday, September 13, 2022 at 10:26:04 PM UTC-7 David Roe wrote:
>
>> My understanding from the 
>> allowing-changes-to-a-pull-request-branch-created-from-a-fork 
>> documentation 
>> 
>>  is 
>> that only users who have push permission on the repository will be able to 
>> make edits to a pull request.  I think the consequence is that we want 
>> active Sage developers to have Write access 
>> 
>>  
>> to the repository, and then use branch protection rules 
>> 
>>  
>> on develop and master.
>>
>>>
>>>
> Yes, please take a look at 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-permissions-and-protections,
>  
> where I have started to write something like this.
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2b08b01b-6220-4efd-8dfa-06f47a95868dn%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Tobias Diez]

Smaller suggestions can also be made through the github web interface as 
part of the pullrequest review, see 
https://egghead.io/lessons/github-add-suggestions-in-a-github-pr-review and 
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request

On Wednesday, 14 September 2022 at 04:15:10 UTC+2 Nils Bruin wrote:

> On Tuesday, 13 September 2022 at 14:04:24 UTC-7 dim...@gmail.com wrote:
>
>>
>>
>> On Tue, 13 Sep 2022, 21:56 Nils Bruin,  wrote:
>>
>>> I'd actually be interested in knowing what the substitute for "git trac 
>>> checkout ..." is. Because with trac, all ticket branches are present in the 
>>> "trac" repository, you can pull anything from there. If I have to 
>>> merge/pull from developer branch, do I need to add another remote to my 
>>> local sage git repository? That sounds very laborious. Particularly for how 
>>> to keep it up-to-date.
>>>
>>
>> No, you don't need to add the remote of the author of the PR, because the 
>> PR is a branch in the main repo.
>>
>> git-trac's functionality is provided by cli, a command line tool ftom 
>> GitHub, so this is all covered (except parts of git-trac only used by 
>> Volker-but you don't need to worry about this)
>>
>> it's explained in some detail in docs prepared by Matthias.
>>
>> Yes, indeed. "gh pr checkout" (
> https://cli.github.com/manual/gh_pr_checkout) looks like pretty much like 
> an exact analogue for "git trac checkout"
>
> What I was not able to find, though, was the equivalent of "git trac 
> push", which can sometimes be very convenient for making a small friendly 
> amendment to a proposed change. I would not expect to be able to push to 
> someone else's fork (I cannot push to someone else's branch on trac 
> anyway), but I can of course push to my own branch -- git-trac in that 
> situation pushes to a branch in my name and does the required magic to tie 
> that branch to the relevant ticket.
>
> It's not clear to me yet what the github analogue of that would be ... I 
> guess a different "pr" could be tied to a given issue. But in that case, a 
> direct analogue of "git trac" would focus on "issues", and pull the 
> currently registered "pr" for a given issue and tie my new branch as a "pr" 
> to that issue if I want to make a change to a ticket.
>
> Perhaps it's nice to address how to "make a friendly amendment" to someone 
> else's "pr" or "issue", or how to collaborate on tickets/issues/pr's . In 
> my work on trac tickets that happened quite a bit and "git trac 
> checkout/push" makes the workflow superconvenient for that. It would be 
> nice to have a convenient convention on how to replicate that on github.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a1ee452c-4706-4871-a6e3-092fae4119f0n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Tobias Diez]

Yes, having "issues" and "pull requests" separated is a huge change to the 
way things are handled on trac. Naturally there are advantages and 
disadvantages for both approaches. In the github world, issues are treated 
more as a list of open tasks and are usually more user-focused. For 
example, a user proposing a new feature or reporting a bug. This is 
reflected in that the discussion in an issue is largely on a meta-level. 
For example, discussing weather the proposed feature is actually needed or 
fit into the roadmap of the project; or for bugs outline how it can be 
reproduced. Discussions in pull requests on the other hand revolve more 
around the proposed implementation, code style and other such feedback.

Misstyping an issue reference is not very common on github since it 
provides a nice auto-completion / hover functionality that displays the 
full name of the referenced issue or pull request.

On Tuesday, 13 September 2022 at 07:25:57 UTC+2 Travis Scrimshaw wrote:

>
>> The downside (that will always remain to me) with GH/GL is anything with 
>>> their web interface is highly decentralized, 
>>>
>>
>> No, no such thing.
>>
>
> The fact that PRs and issues are on two completely different pages is 
> already decentralized. There is no clear single place for discussion, with 
> multiple PRs that can have their own threads.
>
>>  
>>
>>> whereas with trac, things are highly concentrated on tickets, which are 
>>> a single point of reference. Using the GH/GL model, we have all of these 
>>> forks
>>>
>>
>> Irrelevant because in the proposed workflow you never look at another 
>> developer's fork.
>>
>
> This is not true. You do not have a central point for branch access. Now 
> because of PRs that get attached to the main project, they do become 
> centralized. However, I cannot easily share or get a branch from another 
> developer that is not linked by a PR.
>
>>
>> (which we have to tell newbies are not the same as branches and should 
>>> not be used as such).
>>>
>> There is also more manual things we have to type and sync subject to 
>>> human (typo) error. This is likely manageable to me compared to some of the 
>>> other benefits (although I will personally experience none of those). 
>>> Despite this, I still have reservations about the increased pains of 
>>> development from trying to fit a mostly square peg into a round hole, and 
>>> subsequently am still opposed to the move
>>>
>>
>> Sorry, this is just a rant based on nothing
>>
>
> Matthias, your dismissive attitude is not helpful. I am even starting to 
> come around that this move could have benefits that outweigh the costs.
>
> The linking of issues to PRs is something that a human has to manually 
> type in, right? (Just today I mistyped a ticket number on trac.) For trac 
> tickets, you would have had to not realized you were on the wrong page, 
> which is far less subtle. My opposition also based on how easy it is to 
> share and manage different branches and communication of things involving a 
> single issue.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a932a629-9b04-4eb2-be22-5c55ac9c886dn%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Tobias Diez]

Matthias, people have their own workflows that evolved around using trac 
for a long time. It is only natural that there are now questions of how 
these workflows will look like when using github. We should give space to 
such questions following the spirit of "there are no stupid questions". 
Especially since Travis made it clear that its not a hard requirement for 
him to send branches around by email but that he is wondering weather this 
would still be helpful.

On Tuesday, 13 September 2022 at 10:17:58 UTC+2 Matthias Koeppe wrote:

> All, let's please not expand the discussion of exotic workflows. 
>
> Sharing files, sharing branches etc. is a solved problem, with multiple 
> easy solutions. This is not 2005 any more, when having an SVN server was 
> the gold standard to sharing & versioning files.
>
>
> On Tuesday, September 13, 2022 at 1:03:59 AM UTC-7 Matthias Koeppe wrote:
>
>> On Tuesday, September 13, 2022 at 12:57:47 AM UTC-7 Travis Scrimshaw 
>> wrote:
>>
>>> With our current setup, I could push the branch to the server, email you 
>>> the branch name, and you could pull it.
>>>
>>
>> So you're discussing a use case of the trac git server to share a branch 
>> that has nothing to do with a trac ticket.
>> Doesn't sound like anything that needs a solution.
>>
>>  
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/eb743bc1-9e89-4f0f-9cb5-0b7fc6d1bfa7n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Tobias Diez]

It does read very nicely, good job!

On Monday, 12 September 2022 at 22:10:30 UTC+2 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 12:07:13 AM UTC-7 tobias...@gmail.com 
> wrote:
>
>> If you first cloned the main repo and then decide to fork, the common 
>> approach is to rename the origin remote to upstream and introduce a new 
>> origin pointing to the fork. The gh cli is doing this automatically, see 
>> https://cli.github.com/manual/examples ("Forking repositories").
>>
>
> Thanks for the pointer to the GH CLI. It does make sense to follow the 
> defaults there.
>
> I've expanded 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b to 
> distinguish between starting with an existing git clone and starting from 
> scratch.
> I think the description is a bit more user-friendly now.
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f26edacc-f3ef-4e11-b9ec-5fe6b68f12c4n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Tobias Diez]

As much as I agree with this sentiment and personally dislike the naming 
"origin/upstream" as well, it is the most widespread naming convention in 
the fork model. See e.g 
https://docs.scipy.org/doc/scipy/dev/gitwash/development_setup.html I think 
its a good idea to stick to the established convention in the sagemath 
documentation.

If you first cloned the main repo and then decide to fork, the common 
approach is to rename the origin remote to upstream and introduce a new 
origin pointing to the fork. The gh cli is doing this automatically, see 
https://cli.github.com/manual/examples ("Forking repositories").

On Sunday, 11 September 2022 at 19:06:25 UTC+2 Matthias Koeppe wrote:

> Hi Tobias, 
> Thanks a lot for your edits to the wiki page!
> Some comments:
> 1)  In our documentation, we should avoid referring to "origin" as the 
> remote, because what is "origin" will depend on whether someone cloned the 
> repo before deciding that they need their own fork. This is why I used 
> "github-USERNAME" as the name of the remote. It makes it clear to 
> developers what is what.
> 2) Likewise, the word "upstream" is heavily overloaded in our use. I would 
> recommend to call this remote just "sagemath" or something like this for 
> clarity.
>
>
> On Sunday, September 11, 2022 at 12:17:24 AM UTC-7 tobias...@gmail.com 
> wrote:
>
>> On Saturday, 10 September 2022 at 21:32:50 UTC+2 Matthias Koeppe wrote:
>>
>>> On Saturday, September 10, 2022 at 8:12:48 AM UTC-7 Matthias Koeppe 
>>> wrote:
>>>
 I've added a draft of a proposed workflow on GitHub with the idea to 
 just follow the Trac workflow.
 Help is welcome in adding links to documentation for the various bits.

 I think we can have a fleshed out Trac to GitHub transition guide by 
 the end of the weekend.


>>> A draft of the Trac-to-GitHub transition guide is now available at:
>>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>>>
>>> Please let me know what's missing or unclear.
>>>
>>>
>>
>> Thanks, this is already in a pretty nice shape! I've extended some points 
>> a bit.
>>
>> In my opinion, we can also directly drop the develop branch and move to 
>> the master/main-branch only model. But that's slightly orthogonal to the 
>> migration to Github.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4d039b11-ad50-49e0-9338-9fca7fe7e454n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Tobias Diez]

On Sunday, 11 September 2022 at 13:56:11 UTC+2 seb@gmail.com wrote:

> I think an explicit description of what will replace the states of a 
> ticket (for example positive review) is still missing.
>

PR reviews can either request changes (= "needs work") or approve 
(="positive review"). I've added this to the workflow document.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/24629087-f04e-4bfe-a58e-5b9019b7367en%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Tobias Diez]

On Saturday, 10 September 2022 at 21:32:50 UTC+2 Matthias Koeppe wrote:

> On Saturday, September 10, 2022 at 8:12:48 AM UTC-7 Matthias Koeppe wrote:
>
>> I've added a draft of a proposed workflow on GitHub with the idea to just 
>> follow the Trac workflow.
>> Help is welcome in adding links to documentation for the various bits.
>>
>> I think we can have a fleshed out Trac to GitHub transition guide by the 
>> end of the weekend.
>>
>>
> A draft of the Trac-to-GitHub transition guide is now available at:
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>
> Please let me know what's missing or unclear.
>
>

Thanks, this is already in a pretty nice shape! I've extended some points a 
bit.

In my opinion, we can also directly drop the develop branch and move to the 
master/main-branch only model. But that's slightly orthogonal to the 
migration to Github.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6d5f028c-bbb3-45ec-af9d-26f094de8fc6n%40googlegroups.com.

Re: [sage-devel] Re: SageMath and VScode

[Tobias Diez]

VS code cannot debug python code that is executed by a shell script. You 
have to execute python code directly in order to debug it. My strategy 
usually is to create a new (temporary) python file that contains the code I 
want to debug (or calls the method I want to debug), and then use the 
python debug launch config to debug it.
 
On Wednesday, 13 April 2022 at 21:51:14 UTC+2 hohoa...@gmail.com wrote:

> Hi,
>
> phiho has been struggling to step into python code from the shell scripts 
> without success.
> (After installing VSCode client on Windows, remote WSL, Python and Bash 
> Debug extensions)
>
> He couldn't interact with Sage console started in the DEBUG CONSOLE of 
> VSCode (after stepping through sage/sage and sage/src/bin/sage)
>
> Any hint on how to achieve these two things is much appreciated.
>
> Please find attached a screen capture of VSCode.
>
> Regards,
>
> phiho
>
>
> On Wed, Apr 13, 2022 at 11:42 AM Matthias Koeppe  
> wrote:
>
>> See https://trac.sagemath.org/ticket/30484 - help is welcome in writing 
>> instructions for our documentation
>>
>> On Wednesday, April 13, 2022 at 1:33:14 AM UTC-7 hohoa...@gmail.com 
>> wrote:
>>
>>> Dear All,
>>>
>>> There was a related discussion here:
>>>
>>> https://ask.sagemath.org/question/43240/sagemath-and-vscode/
>>>
>>> Is there any way to debug SageMath using VScode client on Windows and  
>>> server on "remote WSL" (on the same machine)?
>>>
>>> Your advice is much appreciated.
>>>
>>> Regards,
>>>
>>> phiho
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/3bc35300-2454-4d5b-a0de-6f62391f846an%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5ec51ac4-8571-4cfb-a77e-03ae489a5f4bn%40googlegroups.com.

[sage-devel] Added branch protection rule for github sagetrac-mirror

[Tobias Diez]

I've now added a branch protection rule for the github mirror, so that one 
can no longer push directly to it (so it's a true mirror now). The sageb0t 
user got an exemption so the sync from trac to the github mirror should 
still work (I've tested it for with a few commits).

Now if someone tries to push directly to the github mirror the following 
error message is shown 
remote: error: GH006: Protected branch update failed for 
refs/heads/public/build/gitpod_trac_tracking.
remote: error: Changes must be made through a pull request.
To https://github.com/sagemath/sagetrac-mirror.git
 ! [remote rejected] public/build/gitpod_trac_tracking -> 
public/build/gitpod_trac_tracking (protected branch hook declined)
error: failed to push some refs to 
'https://github.com/sagemath/sagetrac-mirror.git'

Let me know if you experience any issues with this setup and I'll try to 
fix it promptly.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a2da70b1-2aa6-4c6e-837b-908c4b639f08n%40googlegroups.com.

Re: [sage-devel] Re: sage 9.5 build failed at package numpy-1.21.4 (on Windows Server 2019 WSL)

[Tobias Diez]

>From the logs:
error: Command "gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv 
-O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g 
-fwrapv -O2 -g -O2 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I./sage/cpython 
-I/mnt/g/Maths/sage-9.5/clone/local/var/lib/sage/venv-python3.8/lib/python3.8/site-packages/cysignals
 
-I./sage/rings -I/mnt/g/Maths/sage-9.5/clone/pkgs/sagemath-standard 
-I/usr/include/python3.8 
-I/mnt/g/Maths/sage-9.5/clone/local/var/lib/sage/venv-python3.8/lib/python3.8/site-packages/numpy/core/include
 
-Ibuild/cythonized 
-I/mnt/g/Maths/sage-9.5/clone/local/var/lib/sage/venv-python3.8/include 
-I/usr/include/python3.8 -c build/cythonized/sage/arith/power.c -o 
build/temp.linux-x86_64-3.8/build/cythonized/sage/arith/power.o 
-fno-strict-aliasing -DCYTHON_CLINE_IN_TRACEBACK=1 -std=c99" failed with 
exit status 1
Exception ignored in: 
Traceback (most recent call last):
  File "/usr/lib/python3.8/multiprocessing/pool.py", line 268, in __del__
self._change_notifier.put(None)
  File "/usr/lib/python3.8/multiprocessing/queues.py", line 368, in put
self._writer.send_bytes(obj)
  File "/usr/lib/python3.8/multiprocessing/connection.py", line 200, in 
send_bytes
self._send_bytes(m[offset:offset + size])
  File "/usr/lib/python3.8/multiprocessing/connection.py", line 411, in 
_send_bytes
self._send(header + buf)
  File "/usr/lib/python3.8/multiprocessing/connection.py", line 368, in 
_send
n = write(self._handle, buf)
OSError: [Errno 9] Bad file descriptor

Looks similar to errors I had due to sage's handling of the build/temp.xyz 
folder (combined with a bug in WSL). You can try the workaround of setting 
SAGE_BUILD_DIR  mentioned at the end of 
https://doc.sagemath.org/html/en/installation/source.html#ubuntu-on-windows-subsystem-for-linux-wsl-prerequisite-installation.
 
For me this worked.
On Wednesday, 16 February 2022 at 23:10:25 UTC+1 Matthias Koeppe wrote:

> I think it's a bug in WSL 1. We should update our WSL install instructions 
> to mention this limitation.
>
> You could also try if switching to WSL 2 improves the situation when using 
> the mounted drive.
>
>
> On Wednesday, February 16, 2022 at 12:04:41 PM UTC-8 hohoa...@gmail.com 
> wrote:
>
>> Hi  Matthias,
>>
>> I have just finished the builds for sage 9.5 and 9.6 b01 successfully on 
>> the root drive (instead of mounted drive which was OK for sage 9.4)
>>
>> Thank you so much for your patience. I am wondering what is the problem 
>> with the mounted drive. 
>> Is it a bug in WSL or  a feature in Ubuntu and/or Sage I am concerned 
>> about the limited disk space on the root drive
>>
>> Again, thank you for your help and patience.
>>
>> Regards,
>>
>> phiho
>>
>>
>> On Tuesday, February 15, 2022 at 11:46:41 AM UTC-5 Matthias Koeppe wrote:
>>
>>> I would suggest to try whether the "Invalid argument" syscall errors go 
>>> away if you clone the Sage source tree in the Linux file system, for 
>>> example, in "/sage", instead of a location mounted from the Windows file 
>>> system (/mnt/g/Maths/sage-9.5/clone/).
>>>
>>>
>>>
>>>
>>> On Tuesday, February 15, 2022 at 12:14:30 AM UTC-8 hohoa...@gmail.com 
>>> wrote:
>>>
 Hi,

 Thank you so much for your advice.

 I just started afresh with a new clone from github and following the 
 instructions from https://sagemanifolds.obspm.fr/install_ubuntu.html

 After running './configure', conda was deactivated (twice):

 $ which conda
 /home/hph/miniconda3/bin/conda

 $ conda deactivate
 $ conda deactivate

 Then:

 $ make ccache
 $ MAKE="make -j8" make

 after 10 times of -re-make (with MAKE="make -j8"):

 $ ls -l *.log | wc -l
 152

 $ ls -l *.log.error | wc -l
 12

 All the errors from the earlier make's seemed to be fixed eventually in 
 the later re-make, all except 'scipy-1.7.2' and 'sagelib-9.5'

 Please find attached 'config.log.7z' and 'Error building a wheel for 
 scipy-1.7.2 - scipy-1.7.2.log.error.7z' (from re-make #5 to #10) and 
 'sagelib-9.5.log.error.7z'

 The re-make #10, scipy-1.7.2 failed with:

 *error: Command "gfortran -Wall -g -ffixed-form -fno-second-underscore 
 -g -O2 -fPIC -fPIC -O3 -funroll-loops 
 -I/mnt/g/Maths/sage-9.5/clone/local/var/lib/sage/venv-python3.8/lib/python3.8/site-packages/numpy/core/include
  
 -Ibuild/src.linux-x86_64-3.8/numpy/distutils/include -c -c 
 scipy/interpolate/fitpack/curev.f -o 
 build/temp.linux-x86_64-3.8/scipy/interpolate/fitpack/curev.o" failed with 
 exit status 1*

   ### CLIB COMPILER OPTIMIZATION ###
   Platform  :
 Architecture: x64
 Compiler: gcc

   CPU baseline  :
 Requested   : 'min'
 Enabled : SSE SSE2 SSE3
 Flags   : -msse -msse2 -msse3
 Extra checks: none

   CPU dispatch  :
 Requested   

Re: [sage-devel] Re: New trac status badges

[Tobias Diez]

I agree that linuxbrew might not be most optimal choice for sage. It is 
currently installed by gitpod automatically in their full-image that we 
use. But they are also in the process to restructure their images at 
https://github.com/gitpod-io/workspace-images/tree/master. For example, the 
new workspace-python package seems promising 
https://hub.docker.com/r/gitpod/workspace-python/tags. Maybe wait a bit 
until their tooling is stabilized and then reevaluate what we use as the 
base image? Or do you experience any issues with linuxbrew (except for the 
misleading configure message)? 

On Monday, 14 February 2022 at 11:01:29 UTC+1 dim...@gmail.com wrote:

> Hi,
> I'm testing this on a ticket, and noticed that the Ubuntu host it runs
> on has Linuxbrew installed.
>
> gitpod /workspace/sagetrac-mirror (public/build/github_build) $ which brew
> /home/linuxbrew/.linuxbrew/bin/brew
> As a result, ./configure thinks it's a Homebrew macOS system...
> (This is e.g. trac 32753 - not worked on yet)
>
> Perhaps, if possible, not having Linuxbrew on the host might be a good
> idea, for the time being.
>
> Dima
>
> On Mon, Feb 14, 2022 at 12:15 AM Matthias Koeppe
>  wrote:
> >
> > Thanks a lot for this work, Tobias! Glad to see that it is merged now.
> >
> > I have added a bit based on your posting to 
> https://wiki.sagemath.org/ReleaseTours/sage-9.6
> >
> >
> > On Sunday, February 13, 2022 at 1:26:06 PM UTC-8 tobias...@gmail.com 
> wrote:
> >>
> >> Hi everyone,
> >>
> >> as you probably have already seen, there are a few new status badges in 
> the trac ticket display.
> >> We have now:
> >> 1. Linter that checks that the code of the current branch adheres to 
> the style guidelines. In order to see details when it fails, you can click 
> on it and then select the most recent workflow run. (This already exists 
> for a while)
> >> 2. Buid & test that builds sage for the current branch (incrementally 
> on top of the system packages of the develop branch) and runs the test. 
> Details are again available by clicking on the badge. (This is currently 
> still gray until https://trac.sagemath.org/ticket/33263 is merged into 
> master)
> >> 3. Build documentation workflow that builds the documentation for the 
> current branch. If you click on it, you get the html output of the 
> successful run. The idea is to use this to easily inspect changes to the 
> documentation without the need to locally rebuild the docs yourself. If the 
> doc build fails, you can go to 
> https://github.com/sagemath/sagetrac-mirror/actions/workflows/doc-build.yml 
> and choose the particular branch to see what went wrong.
> >> 4. Open in gitpod. This will spin up a pre-configured dev environment 
> in the browser (based on VS code), where the branch is already checked-out 
> and everything is pre-build. Feel free to use it to quickly check that the 
> changes in the ticket work as expected or to even make further changes 
> yourself. To find out more: https://www.gitpod.io/
> >>
> >> The idea is that these three status badges complement the existing 
> patchbots (and maybe even replace them in the future). In particular, they 
> are supposed to always be green. Please keep this in mind when reviewing a 
> ticket.
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/fa011350-6b93-40e2-948d-a88bce053c35n%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9aa3c364-8e6d-4619-a43d-57f0cfbc7039n%40googlegroups.com.

[sage-devel] New trac status badges

[Tobias Diez]

Hi everyone,

as you probably have already seen, there are a few new status badges in the 
trac ticket display.
We have now:
1. Linter that checks that the code of the current branch adheres to the 
style guidelines. In order to see details when it fails, you can click on 
it and then select the most recent workflow run. (This already exists for a 
while)
2. Buid & test that builds sage for the current branch (incrementally on 
top of the system packages of the develop branch) and runs the test. 
Details are again available by clicking on the badge. (This is currently 
still gray until https://trac.sagemath.org/ticket/33263 is merged into 
master)
3. Build documentation workflow that builds the documentation for the 
current branch. If you click on it, you get the html output of the 
successful run. The idea is to use this to easily inspect changes to the 
documentation without the need to locally rebuild the docs yourself. If the 
doc build fails, you can go to 
https://github.com/sagemath/sagetrac-mirror/actions/workflows/doc-build.yml 
and choose the particular branch to see what went wrong.
4. Open in gitpod. This will spin up a pre-configured dev environment in 
the browser (based on VS code), where the branch is already checked-out and 
everything is pre-build. Feel free to use it to quickly check that the 
changes in the ticket work as expected or to even make further changes 
yourself. To find out more: https://www.gitpod.io/

The idea is that these three status badges complement the existing 
patchbots (and maybe even replace them in the future). In particular, they 
are supposed to always be green. Please keep this in mind when reviewing a 
ticket. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6fa086b9-276e-419e-9232-ff03f2b0708cn%40googlegroups.com.

[sage-devel] Re: Split into interpreter and python package to facilitate development

[Tobias Diez]

Thanks for the explanation, this makes a few things clearer to me! 

The "in-place" builds sounds very promising indeed. I would like to help in 
this direction, but feel like I don't have the knowledge to contribute 
directly. However, if there is something to try-out / play around with, 
please let me know!

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4a76adb2-9190-4c88-b698-1292c3652106%40googlegroups.com.

Re: [sage-devel] Re: Split into interpreter and python package to facilitate development

[Tobias Diez]

 0m24.173s
sys 0m36.523s
tobias@DESKTOP-OMSMBL2:/mnt/d/Programming/Projects/sage$ ./sage -b
cd . && export\
SAGE_ROOT=/doesnotexist   \
SAGE_SRC=/doesnotexist\
SAGE_SRC_ROOT=/doesnotexist   \
SAGE_DOC_SRC=/doesnotexist\
SAGE_BUILD_DIR=/doesnotexist  \
SAGE_PKGS=/mnt/d/Programming/Projects/sage/build/pkgs\
&& sage-python -u setup.py --no-user-cfg build install
/mnt/d/Programming/Projects/sage/src/bin/sage-env: line 130: cd: 
/doesnotexist: No such file or directory
Warning: overwriting SAGE_ROOT environment variable:
Old SAGE_ROOT=/doesnotexist
New SAGE_ROOT=
Discovering Python/Cython source code
Discovered Python/Cython sources, time: 0.91 seconds.
running build
Generating auto-generated sources
Building interpreters for fast_callable
running build_cython
Enabling Cython debugging support
Updating Cython code
Finished Cythonizing, time: 50.39 seconds.
running build_py
running build_ext
Executing 0 commands (using 1 thread)
Time to execute 0 commands: 0.22 seconds.
Total time spent compiling C/C++ extensions: 21.22 seconds.
running install
running install_lib
byte-compiling 
/mnt/d/Programming/Projects/sage/local/lib/python3.7/site-packages/sage/ext_data/nbconvert/postprocess.py
 
to postprocess.cpython-37.pyc
running install_egg_info
Removing 
/mnt/d/Programming/Projects/sage/local/lib/python3.7/site-packages/sage-9.1-py3.7.egg-info
Writing 
/mnt/d/Programming/Projects/sage/local/lib/python3.7/site-packages/sage-9.1-py3.7.egg-info
Cleaning up stale installed files
- cleaning 
/mnt/d/Programming/Projects/sage/local/lib/python3.7/site-packages
Cleaning up stale file: 
/mnt/d/Programming/Projects/sage/local/lib/python3.7/site-packages/sage/ext_data/nbconvert/__pycache__/postprocess.cpython-37.pyc
- cleaning build/lib.linux-x86_64-3.7
Finished cleaning, time: 15.04 seconds.
if [ "$UNAME" = "CYGWIN" ]; then \
sage-rebase.sh "$SAGE_LOCAL" 2>/dev/null;\
fi

real4m25.825s
user0m24.257s
sys 0m36.241s
tobias@DESKTOP-OMSMBL2:/mnt/d/Programming/Projects/sage$


On Sunday, May 31, 2020 at 3:07:40 PM UTC+2, Dima Pasechnik wrote:
>
> On Sun, May 31, 2020 at 1:59 PM Eric Gourgoulhon  > wrote: 
> > 
> > Hi Tobias, 
> > 
> > Le dimanche 31 mai 2020 14:49:46 UTC+2, Tobias Diez a écrit : 
> >> 
> >> 
> >> For now I came up with the following workaround, which works but feels 
> like a huge hack: Create a file `/src/sage/test.py` with the following 
> content. You can then run this file using the local python (e.g. 
> ./local/bin/python3). Once you change the content of the package under 
> consideration (here manifolds), rerun the "Reload manifold packages..." 
> block, which reloads the files so that the changes take effect. This takes 
> about one second in contrast to the 5 min of `sage -b`. 
> > 
> > 
> > I'm surprised about this: usually, when I modify some source file in 
> src/sage/manifolds and I run sage -b afterwards, it takes only about 1 
> second to rebuild Sage. 
> > 
> indeed, if you only touch a *.py file, it will be copied and 
> byte-compiled by ./sage -b, but this would be the only work done by 
> ./sage -b 
>
> if you see more, it could either be that your setup touches a lot of 
> files, or you did actually touch *.pyx files yourself - and they take 
> more time to rebuild. 
>
>
> > Eric. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/b7b265b0-a3c4-48f4-9343-778c3504d424%40googlegroups.com.
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/373944ae-da7f-48fd-a0fa-ff5c15e7988f%40googlegroups.com.

[sage-devel] Split into interpreter and python package to facilitate development

[Tobias Diez]

Hi everybody,

(disclaimer: everything I say comes from a few days of playing around with 
sage's code - so I might make some wrong statements that are obvious to 
more experienced sage devs)

currently `./sage -b` rebuilds the python interpreter part of sage (i.e. 
special syntax support etc) as well as the actual python package (e.g. 
sage.manifolds). This makes development hard as small changes to a package 
(e.g. sage.manifolds.chart.py) need a lengthy recompilation of everything. 
Moreover, the build copies the content of `/src/sage` to 
`site-packages/sage` which makes IntelliSense of vs code go crazy (It seems 
the whole site-packages folder is reindexed after a build, which takes 
really long).
In view of these problems, I think it would be worthwhile to split both 
aspects of sage (interpreter vs library), and make it possible to propagate 
changes to package files without a complete recompilation of sage.

For now I came up with the following workaround, which works but feels like 
a huge hack: Create a file `/src/sage/test.py` with the following content. 
You can then run this file using the local python (e.g. 
./local/bin/python3). Once you change the content of the package under 
consideration (here manifolds), rerun the "Reload manifold packages..." 
block, which reloads the files so that the changes take effect. This takes 
about one second in contrast to the 5 min of `sage -b`.

I hope this is helpful for someone (I doubt I'm the first one facing the 
problem).
Best regards
Tobias

Ps: one complication I faced was that all imports in sage are absolute 
(e.g. sage.manifolds.differentiable.metric) instead of relative (e.g. 
`.metric`). What's the reason for this? 


# This script loads packages from /src/sage instead of site-packages/sage to 
make development easier
# For this to work, the following preparation is necessary:
# - Compile sage using `./sage -b`
# - Remove the imports of the packages from site-packages/sage/all.py
# - Delete (or rename) the packages from site-packages/sage
# Moreover, this file has to reside in `src/sage`, e.g. `src/sage/test.py`

# %% Load sage
import sys
import importlib

# Import sage from site-packages
import sage.all

# Load manifolds and tensor packages from src folder, and put them at 
"sage.manifolds" and "sage.tensor"
spec = importlib.util.find_spec("manifolds")
print(spec) # This should show that the module is loaded from /sage/src/
module = importlib.util.module_from_spec(spec)
sys.modules["manifolds"] = module
sys.modules["sage.manifolds"] = module

spec = importlib.util.find_spec("tensor")
print(spec) # This should show that the module is loaded from /sage/src/
module = importlib.util.module_from_spec(spec)
sys.modules["sage.tensor"] = module

# %% 
# Reload manifold packages (actually not needed on first run, use this if you 
change code in /src/manifolds)
for k,v in sys.modules.items():
if k.startswith('sage.manifolds'):
print(k)
importlib.reload(v)

# Actual imports
from sage.manifolds.differentiable.tensorfield import TensorField
from sage.manifolds.manifold import Manifold

# %% Do what you want here
M = Manifold(2, 'M'); M
XM = M.vector_field_module()


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/57689c6f-14dc-4056-ba4b-ba0c7dad4b43%40googlegroups.com.