New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python library to bootstrap Sage #18748
Comments
This comment has been minimized.
This comment has been minimized.
Commit: |
comment:5
Now with testing:
|
Author: Volker Braun |
comment:6
Can you explain in detail what you do in this branch? You make many changes, this ticket is now a blocker, and it takes a LONG time to figure it all out from looking at the diff. |
comment:7
|
comment:8
Also: why is this a blocker? There is nothing in the description or comments justifying that. |
comment:9
About the directory structure: wouldn't it be simpler to keep the scripts in |
comment:10
I honestly have no idea what
Also, I'm a bit confused by
followed later by
|
comment:11
What would it take to support Python <= 2.5 or Python <= 3.2? I don't know how common these are, but if they can be supported with minimal effort, perhaps it should be done. |
comment:12
I don't think there is any currently supported OS that ships with those python versions, so its most likely a waste of time to try. |
comment:13
Blocker because it fixes the firewall issue from #18723 and that ticket was a blocker. |
comment:14
I don't mind renaming the script, but I don't see the point of avoiding name collisions with historical Sage versions. My plan is to export all new-style package management functions via sage-pkg so its the obvious name for that. tox (which is pretty much the standard for cross python version testing) is configured to not fail if a python version is not found (see tox.ini) scripts in src/bin end up being installed in SAGE_LOCAL (and globally if Sage is every packaged / packageable). Build tools shouldn't be globally installed. Really sage-bootstrap only makes sense if you have the source lying around, so why pretend otherwise. |
comment:15
Replying to @vbraun:
It's a name collision with current Sage versions. And
Sure, but it is confusing to see |
comment:17
THis is a rather simple ticket IMHO, it just refactors a script and adds testing. |
comment:18
Wouldn't it be a lot better to move |
comment:19
Replying to @vbraun:
Really?
|
comment:20
You have inconsistent indentation (not multiples of 4 spaces) in |
comment:42
The whole point of the refactoring is to make stuff testable |
comment:43
Why are some of the files not listed in |
comment:44
The manifest is auto-generated by tox/distutils to build a package for testing purposes. Its contents don't really matter apart from that. The tox config file arguably doesn't belong there, so I'd count that as a plus. If we were to use the manifest for anything then we would have to add a |
comment:45
Minor questions:
there just for testing via
Overall, the code is just a relocation of old code, so that's okay. I'm not sure about the whole idea of moving it. Seems okay to me, but it doesn't strike me as very high on the priority list. Less minor questions and comments:
(Something like "The main entry points are sage-download-file and sage-package, which are used as follows: ...". Note also that "libary" is currently misspelled.)
|
comment:46
Replying to @jhpalmieri:
They are used for testing in unittest.TestCase.assertEqual, doesn't really have anything to do with tox (which is just the test runner) besides that.
I don't.
The old script was already too long to fit comfortably into one file, with added testing its can't fit into one file. So it has to grow into a package.
It mostly makes the release manager's job easier because you don't have to log into the server and associated tarball names to package names by hand, which wastes my preciously little available time. I'm happy to add a line of documentation here or there but unlike the math part this is not a library for Python novices. IMHO its not too much to ask to google for "tox", thats bound to produce way more relevant and informative information than I can possibly be. |
Changed branch from u/vbraun/python_library_to_bootstrap_sage to u/jhpalmieri/python_library_to_bootstrap_sage |
comment:48
Replying to @vbraun:
Here is some documentation for the main scripts. I think that few of the Python files could use a bit more information: the current descriptions for |
Changed branch from u/jhpalmieri/python_library_to_bootstrap_sage to u/vbraun/python_library_to_bootstrap_sage |
Changed branch from u/vbraun/python_library_to_bootstrap_sage to u/jhpalmieri/python_library_to_bootstrap_sage |
Changed branch from u/jhpalmieri/python_library_to_bootstrap_sage to u/vbraun/python_library_to_bootstrap_sage |
comment:52
Done, still needs review |
comment:53
I get an error with tox:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:55
Thanks, ``assertIsInstance` is Python 2.7+, fixed |
Changed branch from u/vbraun/python_library_to_bootstrap_sage to u/jhpalmieri/python_library_to_bootstrap_sage |
Reviewer: John Palmieri |
comment:57
Okay, one more addition to the documentation. If you're happy with this, you can set this to positive review. |
Changed branch from u/jhpalmieri/python_library_to_bootstrap_sage to |
Move the logic behind package handling and I/O for Python scripts into a separate Python library for code reuse and automated testing.
CC: @nathanncohen
Component: build
Author: Volker Braun
Branch/Commit:
60a581b
Reviewer: John Palmieri
Issue created by migration from https://trac.sagemath.org/ticket/18748
The text was updated successfully, but these errors were encountered: