Hi Samuel, On 2018-04-08, Samuel Lelievre <samuel.lelie...@gmail.com> wrote: >> 2. The vast majority of my spkg's tests start with calling a function >> that is responsible for providing data on a cohomology ring; if the >> data is locally available, then it is just loaded; if it isn't, but >> internet is available, then the data is downloaded; if it isn't, then >> the data is computed from scratch. So, mathematically the functions do >> not depend on the data from internet; but they do try to access them >> unless local data are available (which in many tests aren't). > > Maybe such a function could take optional arguments such as > > def f(..., get_data_from=None)
I think one should distinguish two issues: Where to get data from? Where to write data to? Let me give some background that may explain how I came to the current design. Early in the development of the spkg I found that it is unfeasible (in the big examples that have been part of my project) to keep the whole structure of all cohomology rings in memory all the time. So, parts of the structure that are currently not in use are stored on disk. That's why there has to be a folder assosiacted with a cohomology ring. To keep things orderly, the folders for each individual ring are all contained in a single root folder, which is what I refer to by "location of a database". Of course, a user's computations must not interfere with other user's computations. That's why *all* cohomology rings belong to a private database located somewhere in DOT_SAGE, even if they were loaded from some public database or from the web. Usually, computing a cohomology ring involves computing several other cohomology rings as well: If G is a finite group, p is a prime, and S a Sylow p-subgroup, then computing H^*(G; GF(p)) with my spkg involves the cohomology rings of - The maximal p-elementary abelian subgroup in Z(S) - All maximal p-elementary abelian subgroups in S - S - N_G(Z(S)) - G For simplicity, I want that all these rings belong to the same private database, and thus I have a global option defining the location of *the* private database that is used for all rings. Similarly I have global options for the location of the current public database and the current web database. But your remark made me reconsider: While there is reason to only have a single private database (to *store* stuff), it should be perfectly fine to simultaneously have more than one public database and more than one web database - or *no* public database resp. *no* web database. So, I would modify your idea as follows: - I will keep the global option for the location of *the* private database. - I will extend the current global options for the location of public and web database: They should become *tuples* of strings, rather than single strings. The resources are then tried in order: First all private database, then all public databases, then all web databases. If that fails, the ring will be computed from scratch. - There should be an optional argument `public_dbs` and `web_dbs` that override the global options for public and web databases. Or perhaps the wording `local_dbs` instead of `public_dbs` would be clearer. And since internet during tests during installation is a problem, I'd set web_dbs=() globally at the beginning of each doctest. > Then the doctests could be split into some that require internet > (which would be tagged # optional -- internet), and some that don't. Again: The tests will almost always be executed during installation, and thus there definitively is no internet. So, "# optional -- internet" cannot be a solution. Instead, I will ban internet access in all tests by setting the global web_dbs appropriately, except in the tests of the functions that get data from web databases. These tests don't need to change, as I am using a *local* toy database in the format that's used by an actual web database. Thank you for your feedback and suggestions! Best regards, Simon -- 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 post to this group, send email to firstname.lastname@example.org. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.