In the para 1., i have to "edit" the file docker-compose-override.yml but i was not able to find this file. I think I have to create it in the swh-docker-dev repository. Then, it seems to me the first code block is not correct: is the identation of swh-listers correct?
In the para 2., it's not easy to follow instructions of the README of swh-lister:
from where comes the tool createdb?
how can i deploy a postgres database?
how to get the python module swh.lister.cli?
I think I have to use swh-environment and/or swh-docker-dev repositories, but it's not clear to me!
Actually, it would be really nice have this kind of tutorial on a hello-world example, with all required steps explained on the same page.
Of course, i understand this is time consuming and boring to do ;)
But, i would be happy to help you improving such kind of tutorial by being a beta tester!
, i have to "edit" the file docker-compose-override.yml but i was not able to find this file. I think I have to create it in the swh-docker-dev repository. Then, it seems to me the first code block is not correct: is the identation of swh-listers correct?
Yes, you have to create it.
In the swh-docker-dev repository, there is a sample committed.
We did not created/committed a docker-compose.override.yml since it's not a generic file. It's user oriented file.
For the indentation, i don't know, might be indeed.
Here is mine as another example (which actually works ;)
SWH_ENV_HOME is an env variable of mine to avoid repetition (it's where my swh-env is located). I quite like it as it allows agnostic documentation (too bad i'm not pushing more to integrate it everywhere).
In the para 2., it's not easy to follow instructions of the README of swh-lister:
Well, it kinda depends how you choose to deploy (docker-dev or your own machine...).
We'd rather the user choose the swh-docker-dev path though (reproducibility, less cogs to set up for the user, less hassle on our part to understand what's wrong on the user's machine ;).
from where comes the tool createdb?
That most probably came from the swh.lister.cli.
It seems that it no longer goes by that name though.
It's exposed through the cli now with either (use the first 1).
swh lister db-init -hUsage: swh lister db-init [OPTIONS] [github|gitlab|bitbucket|debian|pypi|npm|p habricator|gnu|cran|cgit|packagist|all]... Initialize the database model for given listers.Options: -d, --db-url TEXT SQLAlchemy DB URL; see <http://docs.sqlalchemy.org/en/lat est/core/engines.html#database-urls> -D, --drop-tables Drop tables before creating the database schema -h, --help Show this message and exit.
or:
python3 -m swh.lister.cli db-init -h
Note: In docker-dev, the db is already setup though.
how can i deploy a postgres database?
Mmm, installing the postgres service, create a role for your user (as postgres, createrole lewo), create the db (createdb from postgres tool)...
But really, this should already be done in docker-dev.
To ensure this, take a look at the docker logs when booting up services.
docker-compose logs --follow swh-lister
You should mention of db initialized.
how to get the python module swh.lister.cli?
following the main tutorial, you should have virtualenv setup.
So, in the following, i'll call that virtualenv swh
$ workon swh $ cd swh-lister$ pip install -e . # to install from the current repository cloned$ pip install swh-lister # or to install from pypi
Actually, it would be really nice have this kind of tutorial on a hello-world example, with all required steps explained on the same page.
Indeed.
Of course, i understand this is time consuming and boring to do ;)
Well, for my part, the boring part is not the issue ;)
The issue is trying to find the sweet spot on being clear without being too much redundant (in between docs we have...).
I guess we should make clear (if not already), we want people to use the swh-docker-dev environment.
And continue documenting with implicitely relying on this.
Then, we could slice and dice in the lister README (it is confusing right now).
But, i would be happy to help you improving such kind of tutorial by being a beta tester!
I've deployed the docker compose stack and I'm trying to run the lister locally. In the lister README, the provided Gitlab Python snippet needs to be updated since I get
Traceback (most recent call last): File "test.py", line 9, in <module> 'per_page': 20 File "/mnt/data/home/lewo/repos/swh-environment/swh-lister/venv/lib/python3.7/site-packages/celery/local.py", line 191, in __call__ return self._get_current_object()(*a, **kw) File "/mnt/data/home/lewo/repos/swh-environment/swh-lister/venv/lib/python3.7/site-packages/swh/scheduler/task.py", line 45, in __call__ return super().__call__(*args, **kwargs) File "/mnt/data/home/lewo/repos/swh-environment/swh-lister/venv/lib/python3.7/site-packages/celery/app/task.py", line 394, in __call__ return self.run(*args, **kwargs)TypeError: full_gitlab_relister() takes 1 positional argument but 2 were given
It seems to be better when I unpack the kwargs. I then get this log but I don't know what to do next:/
Lister's input are forge's url (among other things).
Lister's output are scheduling tasks (for loader) in the scheduler db (with their arguments set for the loader to take it on).
To know what table is what for the lister you could check the python module swh.lister..models, the db table should be explicited there (or \d in the psql repl from the last sample).
Hi @ardumont,
I see this issue contains a lot of good materials for a How to guide.
can you move this issue to the appropriate repository in your opinion.
I'm moving this to documentation repository.