GitLab

it's not actually necessary but holds underlying _sessions dict handling.
Drop backward compat relying on it (which IMO should not be a problem).

Drop import of unused QueryError along the way.

This is no longer need now that we call load_available_configurations() in the
"list" command (see 5e7282bdf140).

This will be used to build a CubicWebPyramidConfiguration in following
changeset.

The file got removed in 1b9fd8bda1cd.

So that users do not get prompted with this. Follow-up on c34590161082.

This commands starts the repository scheduler as a standalone process that
should complement a CubicWeb web instance running as a WSGI application.

Added a log message in repository's shutdown method to help testing the
command (i.e. make sure the method is called after the scheduler stopped).

Related to #17057223.

None of the caller of this method need the repository to have a scheduler and
having a scheduler should be something that's explicitly requested.

Related to 17057223.

Repository() does not accept anymore a 'tasks_manager' argument but rather a
'scheduler' argument which is expected to be an instance of sched.scheduler
class. The drop the _tasks_manager attribute of the repository and adjust all
internal usages of it. In particular, in the 'repo_stats' service we do not
export 'looping_tasks' statistics anymore as there's no way to retrieve this
anymore from a web instance.

Closes #17057223.

We just use the sched module from the standard library and introduce a tiny
Python2/3 compatibility layer (more for convenience actually). The "looping"
aspect of tasks (previously in LoopTask class) is re-implemeted as a
`schedule_periodic_task` function. This is a reasonably thin layer as compared
to LoopTask/TasksManager classes. Only the "restart" aspect of LoopTask is no
longer present as I'm not sure it's worth keeping.

The advantage of using this (in addition to eventually dropping our custom
code) is that this scheduler class provides a `run` method that blocks the
process while running tasks in its queue. So we can rely on this to have a
'scheduler' ctl command (see forthcoming patch) that would only run "looping
tasks" without having to implement the "blocking" aspect ourself.

Related to #17057223.

We are about to drop this method from Repository class and replace it by a
blocking alternative. This is not compatible with how things currently work in
a Twisted server implementation. So do not start repository "looping tasks" in
Twisted server anymore and issue a warning about this.

If someone is interested in restoring the "all-in-one" behavior where the
repository runs within a Twisted server, they may start by implementing
repository looping tasks using a Twisted mechanism such as, e.g.,
http://twistedmatrix.com/documents/current/core/howto/time.html and eventually
provide the repository with a compatible scheduler instance so that is can
register its periodic tasks. At the moment, we lack resources to do this (and
maintain the Twisted server of CubicWeb in general).

Related to #17057223.

a03376213747 introduced a slight modification in None / empty string values and
with it a regression where an exception is raised on empty values, while we
should simply consider no value is specified and return None.

Remove unused and reorder, + use bare unittest along the way.

We are about to drop the start_looping_tasks method and running "looping
tasks" along the WSGI application is not a very good idea. So issue a warning
pointing to the forthcoming "scheduler" command.

Related to #17057223.

It's unlikely that these implementations were ever used so we do not bother
with deprecation or a warning. We just drop the call to this method which
should not be called from within a WSGI application.

Related to #17057223.

This is a missing bit from 5de78b6fff2e. Unfortunately this code appears to be
uncovered by our test suite.

This is actually not useful as logging is already initialized and configure
"somewhere else" where the repository is started.

We actually never supported this in cubicweb, but only in pyramid-cubicweb.

Not sure anyone ever really used the latter and the former is certainly more
reliable/tested.

This is shown when twisted is not importable and we suggest to use 'cubicweb
pyramid <appid>' instead. Since 3.24, cubicweb-pyramid got merge in cubicweb
so drop this reference in the message.

This comes from a copy-paste in d92d75b17a85.

cubicweb.server is no longer conditionally shipped, neither in python package
nor in debian package since 3.24.

Now that we have guarded all calls to Repository.looping_task() in
'server_startup' hooks we can execute this hooks category at bootstrap step.
This way, repositories running without a tasks manager (i.e. those embedded
into a WSGI application) will have these hooks triggered.

And use a LRU cache over cached_build_user function.

This looping task is problematic because it would not be run from within a
WSGI application which does not have a repository with a tasks manager.

This pulls an explicit dependency on 'repoze.lru' but it's not a big deal
since pyramid already depends on this. RPM spec file not update since it does
not even mention pyramid...

This prepares for calling Repository's _prepare_startup() in bootstrap() so
that repository instances without a tasks manager running can still have their
'server_startup' hooks triggered (this is particularly useful for BFSS
storages).

We do not call repo.start_looping_tasks() for the instantiated repository, so
a tasks manager is useless.

Thus we now call 'bootstrap' here and there explicitly and remove call of this
method in Repository.__init__(). This way instantiation of a Repository does
not *implicitly* triggers the "bootstrap" step, which is arguably not a
trivial thing and thus deserves to be independent.

In __init__, set 'shutting_down' attribute to None and then to False in
bootstrap as a mean to indicate that, when initialized, a repository is
neither shutting down nor started (not sure where this is used though).

See the (removed) docstring for a rationale...

[server] Replace server config's init_cnxset_pool attribute by a "bootstrap" parameter in Repository

This 'init_cnxset_pool' class attribute is actually used to control whether a
Repository instance should be "bootstraped" (see Repository.init_cnxset_pool()
for a definition of "bootstrap") or not. I seems clearer to me to have this
controlled by a boolean "bootstrap" initialization parameter in Repository.