biblib-service

Astrophysic Data System's library service

development

NOTE: This method is now deprecated and only works on x64 machines.

A Vagrantfile and puppet manifest are available for development within a virtual machine. To use the vagrant VM defined here you will need to install Vagrant and VirtualBox.

• Vagrant
• VirtualBox

To load and enter the VM: vagrant up && vagrant ssh

tests

Run the tests using py.test:

docker run --name some-postgres -e POSTGRES_USER="postgres" POSTGRES_PASSWORD="postgres" -p 5432:5432 --name postgres
virtualenv python
source python/bin/activate
pip install -r requirements.txt
pip install -r dev-requirements.txt
py.tests biblib/tests/

Layout

Tests are split into three (excessive) stages:

1. Functional tests (biblib/tests/functional_tests/): this tests a workflow, for example, a user adding a library and then trying to delete it - and testing everything behaves as expected via the REST work flow
2. Unit tests, level 1 (biblib/tests/unit_tests/test_webservices.py): this tests the above workflow on the REST end points
3. Unit tests, level 2 (biblib/tests/unit_tests/test_views.py): this tests the logic of functions that are used within views (end points), and is usually the most fine grained testing
4. Other unit testing: other tests that are testing other parts, such as manage scripts are in their own unit tests, e.g., biblib/tests/unit_tests/test_manage.py.

All tests have been written top down, or in a Test-Driven Development approach, so keep this in mind when reading the tests. All the logic has been built based on these tests, so if you were to add something, I'd advise you first create a test for your expected behaviour, and build the logic until it works.

Running Biblib Locally

To run a version of Biblib locally, a postgres database needs to be created and properly formatted for use with Biblib. This can be done with a local postgres instance or in a docker container using the following commands. config.py must also be copied to local_config.py and the environment variables must be adjusted to reflect the local environment.

docker run -d -e POSTGRES_USER="postgres" -e POSTGRES_PASSWORD="postgres" -p 5432:5432 --name postgres  postgres:12.6
docker exec -it postgres bash -c "psql -c \"CREATE ROLE biblib_service WITH LOGIN PASSWORD 'biblib_service';\""
docker exec -it postgres bash -c "psql -c \"CREATE DATABASE biblib_service;\""
docker exec -it postgres bash -c "psql -c \"GRANT CREATE ON DATABASE biblib_service TO biblib_service;\""

Once the database has been created, alembic can be used to upgrade the database to the correct alembic revision

#In order for alembic to have access to the models metadata, the biblib-service directory must be added to the PYTHONPATH
export PYTHONPATH=$(pwd):$PYTHONPATH
alembic upgrade head

A new revision can be created by doing the following:

#In order for alembic to have access to the models metadata, the biblib-service directory must be added to the PYTHONPATH
export PYTHONPATH=$(pwd):$PYTHONPATH
alembic revision -m "<revision-name>" --autogenerate

A test version of the microservice can then be deployed using

python3 wsgi.py

deployment

The only thing to take care of when making a deployment is the migration of the backend database. Libraries uses specific features of PostgreSQL, such as UUID and JSON-store, so you should think carefully if you wish to change the backend. The use of flask-migrate for database migrations has been replaced by directly calling alembic.

Feature additions

Please see the issues page for lists of features that have been kept in mind during the building of private libraries.