Is there a reason for packaging this?
If the tests fail, maybe the whole package is incompatible with newer flask versions?

I don't think we should package flask packages in Nixpkgs. None of our software needs it, and it typically is a pain to maintain because of dependency incompatibilities.

Also, if you have multiple packages that relate to each other that you want to get in, then please open a single PR with multiple commits. Often that works better.

Is there a reason for packaging this?

Yes, it is a dependency of the sage notebook.

If the tests fail, maybe the whole package is incompatible with newer flask versions?

The sage notebook tests pass with it, so I don't think thats the case.

I don't think we should package flask packages in Nixpkgs. None of our software needs it, and it typically is a pain to maintain because of dependency incompatibilities.

There are already some flask packages and I'm packaging sagenb, which does depend on it.

Also, if you have multiple packages that relate to each other that you want to get in, then please open a single PR with multiple commits. Often that works better.

I'll keep that in mind for the future.

@timokau I suggest you create a sagenb overlay instead of trying to get these packages into Nixpkgs. I've checked the other PR's, and most packages haven't seen a release or commit in several years. Now, they may still be working, but without a passing test suite I don't think we should include this.

+1 for putting sage in an overlay
I think some of the C libraries that don't need patches from the sage team can still included in Nixpkgs without a problem.

Actually, should this overlay only contain sagenb or all of sage?

As an overlay it would be more effort to maintain, more effort to install and would not have the benefits of binary substitutions. I'd be disappointed if there is no way around it but I can't do anything against it of courrse.

I really don't see the big burden of these packages. If they fail to build, they can be disabled or removed. If thats still a problem, I can inline them into the sage expression and not expose them to the nixpkgs tree.

As an overlay it would be more effort to maintain

I don't see why.

would not have the benefits of binary substitutions

Most of the PRs consisting of C libraries were already merged anyway. These profit the most from binary substitution.
The more problematic packages seem to be related to sagenb. How important is sagenb for distributing a functional sage environment?

I don't see why [it would take more effort]

Because failures cause by changes in dependencies would no longer be caught at the PR introducing these changes (or shortly after), but just when somebody builds with the new nixpkgs. That makes it hard to find where the changes were introduced. Fixing all this would probably fall on me.

Most of the PRs consisting of C libraries were already merged anyway. These profit the most from binary substitution.

sagelib itself takes significant time to compile (in the realm of half an hour).

The more problematic packages seem to be related to sagenb. How important is sagenb for distributing a functional sage environment?

It would at leas need some doctest patching, because sagenb is expected by sagelib. I'm not sure if it would take more than that. But even just that would need to be maintained on updates and might introduce new uncaught bugs.

Because failures cause by changes in dependencies would no longer be caught at the PR introducing these changes

Those updating/modifying dependencies are also not going to make sure all dependents are going to work. If you need a package, you need to maintain it, but typically also put in some effort to guarantee the entire dependency tree builds. This especially is lacking with the Python packages which are also tightly connected.

@FRidh What's your opinion on inlining the rejected packages' expressions in the sagenb expression?

I think we should definitely first of all talk to upstream about whether they are willing the get rid of the outdated dependencies (flask-openid, flask-oldsessions and maybe flask-autoindex).

Those updating/modifying dependencies are also not going to make sure all dependents are going to work.

They usually should. But even if they don't, hydra will catch it shortly after.

If you need a package, you need to maintain it, but typically also put in some effort to guarantee the entire dependency tree builds. This especially is lacking with the Python packages which are also tightly connected.

I and hopefully others would maintain it in the nixpkgs tree. Maintaining it as an overlay would make that harder and I don't see it as a big advantage.

I think we should definitely first of all talk to upstream about whether they are willing the get rid of the outdated dependencies (flask-openid, flask-oldsessions and maybe flask-autoindex).

Agreed.

What's your opinion on inlining the rejected packages' expressions in the sagenb expression?

That is one possibility that could work. It's like an overlay but in-tree and as we do for other, though smaller, applications. First, though, I would like to see a branch with a functioning sage / sagenb. With one change at a time it is very hard to see how it will end up.

+1 for having a single branch/PR with all new packages

Brial and cypari2 look mostly fine as they are while the others require many sage-specific patches, so I'd say we can merge these two and you can put all other packages in a single branch.

I think we should definitely first of all talk to upstream about whether they are willing the get rid of the outdated dependencies (flask-openid, flask-oldsessions and maybe flask-autoindex).

I opened sagemath/sagenb#440, I hope I described your concerns accurately.

First, though, I would like to see a branch with a functioning sage / sagenb. With one change at a time it is very hard to see how it will end up.

I'd prefer to first incrementally upstream all the non-controversial changes because

• Many of them are useful with or without sage
• Its easier to review
• Its easier for me to polish the packages one-by-one
• Easier to deal with merge conflicts
• Big PRs tend to rot, especially in nixpkgs

I can then include the controversial ones (hopefully not many) in one PR together with sage itself if you prefer.

If you have further questions about Sage, there is a dedicated mailing list for packaging: https://groups.google.com/forum/#!forum/sage-packaging

Thanks for that pointer! I don't think this problem could have been solved by that mailing list however -- best case somebody has a patch that removes those dependencies, in which case that should probably be upstreamed anyways.