regro / regolith Goto Github PK

It seems a couple of things are shared between the CV and pub list builders. I imagine other things that write to latex templates would want those things as well.

It might be nice to have a JSON Schema for the dbs. (this is related to the validation stuff)

AKA my first time with regolith

Any interest in sub projects? The idea that each project could have various sub projects where each sub projects roughly maps to one repo. This would allow us to put release info and badges on the project page.

My browser shows white on white.
http://www.ergs.sc.edu/regolith-docs/rc.html

It might be nice to have integration tests.
These tests might include having a fake research group which we run tests against. This way we can make sure that we don't break anything major when PRing.

This will require changing of the resume/cv builder or template to properly understand that service can either have a single occurrence or a start and stop.

Some people may have a couple of affiliations. This will be helpful if we use this in conjunction with rever to template/release papers.

It may be nice to actually generate the index.html and base.html pages for the website.
Currently index.html is used by the app.
This may also help with #1

Track the collaberators

It's ok to include work that one edited

It might be nice to have something somewhere (in the rc?) that specifies which pages/methods get run since not every group will have/want all the page types.

This is distinct from a CV

How is sensitive data handled?
Is there a password protected section of the website?

It may be nice to be able to track a project (potentially privately, or with public/private chunks).
Eg. Track on a given project

1. Collaborators
2. When samples were shipped/measured
3. Data analysis status
4. Paper status
5. Software commits/PRs/Repos associated with a project.

At the very least it may be beneficial to track all the papers associated with a public project.

Need to edit the CV builder/template to include a service section.

The command would run schema validation against all databases in the RC. (This could be helpful as a git hook pre-commit for commits to dbs.)

a la: http://slapper.apam.columbia.edu/bib/

It seems that on windows YAML tries to load the yaml files with cp1252 encoding, which causes breakage

ie setup.py still lists 0.1.2, even though we are on 0.1.5

Oops 🐑

It might be nice to track all the conda-forge/pypi packages managed by a research group, since packaging is an important piece of getting software to users. It may also help to show the large impact that software group's packaging has on the community.

It would be nice if people's preferred pronouns appeared on their page and CV.

It may be helpful to go through a few use cases/best practices in the docs to get everyone up to speed:

1. How do I initialize the system?
2. How do I update things?
3. How this integrates with Doctr?
4. Where do I put my more private data (not in a public github repo)?

It might be nice to have some templating for grant reports. It might not get everything, but it would get some of the important info (eg published deliverables in the reporting period)

How do we handle current and former members?

Maybe have a dict of these kinds of external keys?

If the user tries to put in bad json, then when the page is re-loaded then all their work is gone. This is rather nasty as they could have put a lot of work into their entry. Maybe we can reload the existing string? This may also be helped by moving to yml

Flask already checks for valid json, it would be good to check it against the schema as well.

It seems that ingest citations writes a bunch of {'$set': 'bla'} stuff into the db which breaks the author checking. Is the '$set' stuff intentional?

When running interactively (or with builders which use both the public and private dbs) it may be nice to be able to combine similarly named dbs with the same _id. Eg a public project entry may have some information but the private entry keeps track of accounting, ongoing work, etc. but when we go to build an internal report we want both dbs to be accessed together.

In addition to making certain that the combined DBs pass some validation, it may be helpful to have validation on a per db basis.

It would be nice to have a link to the collection schema (if it exists) in the app page for that collection. This way if you needed to remember what the schema was, just go look at it!

Have pity on poor Travis (and those that maintain the sacred yml).

This may need to go somewhere else, but it seems that the citations don't have their latex math rendered.
How do we fix that?

Have an import for running interactively in ipython

It may be nice to have the ability to override parts of the schema in the RC.

Can we just inherit from dict for the RunControl class?

It might be nice to test the app (especially as most people probs, don't want to deal with everything manually)

This may never happen in production (only because of some git trickery by Chris?) but I am recording it here for full disclosure.

1. tried to run regolith app in my rg-db-private repo and got this:
   

2. failing with a git error, but git status shows everything is clean.

3. Chris tells me I need to run git in _build/_dbs/billingegroup_private (not obvious to the casual user)

4. indeed find some uncommitted things in there which I commit and push

5. push fails because I am behind, so try and pull, but have conflicts.

6. resolve conflicts and commit.

All in all, I don't think it is a bug (a feature maybe?) but I am putting it here as a potential thing that may crop up for other users......though I can't quite imagine how.

It might be nice to have each project on the project webpage to track the publications/software releases that are associated with the project. Should we keep track of the publication ids in the project or the project in the publication?

Attn: @sbillinge

It would be nice to have some hooks to/from rever.
Examples:

1. When a software version is released, the software releases table (which doesn't exist, yet) gets updated
2. As a paper is getting ready for submission use rever to push updates on the status to regolith dbs (eg, use rever to release a "submitted", "in review", "accepted" version of the paper)
3. Similar to above for posters

It might be nice to include the arg parse information in a dict. This way to add a command we just update the dict