Using python.get_install_dir(pure: false)
solves this. Please document this somewhere.
Bug description:
Using install_dir : python.get_install_dir() / subdir
instead of subdir : subdir
in python.extension_module
causes the output to not be installed.
Expected behaviour:
install_dir : python.get_install_dir() / subdir
behaves the same as subdir subdir : subdir
Background: I am trying to package SWIG-generated bindings. SWIG dynamically generates python sources so that python.install_sources can not be used, because it expects the files to be present at invocation of meson.
For that reason I have to use custom_target to install the generated python sources. However, custom_target knows nothign about the python installation path so that we have to use install_dir
.
A workaround for packaging the generated python headers would be much appreciated, too.
The method is implemented with a simple n-tree. This allows losing the dependency on networkx (~9MB).
I dislike the abstraction layer because it is based on django-extensions and it hides the choice from the user/administrator how and when to update the search index (which is an inherent "feature" of django-extensions).
The use case you mention hardly justifies the current mechanism as it can easily be implemented by creating an additional management command which would be transparent for the admin.
I can not simply disable the minutely cronjob because the whole django-extensions framework may very well trigger other jobs that need to be run at that frequency (although to my knowledge there currently are none). Which jobs are run how often is invisible for the administrator.
The 95% are guess of the percentage of deployments that do not have extremely high load.
The QueuedSignalProcessor
sounds good, too.
Anyway. Since nobody else has entered the discussion during the last 9 months you are probably right in closing this MR.
How is that a problem? The update-index management command (or "job") typically runs as an hourly cronjob. Setting the age to 1h (or 70min to be on the safe side) does the job without having to query the DB and without the need for the additional abstraction layer.
Besides, the other proposal in this MR which I consider even more important has not been addressed: The idea of using the RT signal processor hook of haystack to index emails by default. Changing to the manual indexing is a matter of one configuration change but should not be necessary for 95% of the deployments.
Anything left for me to do here?
Ah that explains the confusion ;).
What I call "django job" is a job run by the django-extensions
module, see http://django-extensions.readthedocs.io/en/latest/jobs_scheduling.html.
In order to run the "django jobs" django-extensions relies on cron jobs that periodically execute the django management command runjobs hourly/weekly/...
.
django-extensions than runs the "django jobs" that are defined to be run at the respective interval.
So "django jobs" and management commands are two completely separate concepts.
So for once there is nothing gained from using django jobs except that you don't have to configure an additional cron job. The big disadvantage of a django job (compared to a management command with a separate cron job) is that the user can not control at what interval the job is run because that is defined in the job itself.
In this particular case it makes even less sense to use a django job because django-haystack literally includes a management command.
I'll defer this one.
Hyperkitty uses an outdated package for the detection of robots for a single view to reduce load. This removes this specific use and thus drops the dependency on robot_detection.
What are your thoughts?
Exactly. That is why I said that we don't need additional tests.
The logic that queries the time of the last update also is completely unnecessary because the runs are controlled by a cron job (either with or without the django job in between), hence the time since the last update is known.
That said, using a "django job" for this is utterly unnecessary.
Triggering the index update directly by a cron job would allow the user to tune at which intervals the updates are run (depending on the load) or decide to use the RealtimeSignalProcessor, which can be configured in the project's settings.py.
I already tried that unsuccessfully. Since I checked the "squash commits when merge request is accepted" this should not be a problem.
The real change here is to remove the django job (which is triggered by a cron job) in favour of a real cron job as it is intended by django-haystack.
The advantage of the RealTimeSignalProcessor
on the other hand is, that it does not require any additional setup (such as cron jobs) and just works. But if you don't like it we can also not make it the default and state very clearly, that a cron job is required for full text search to work.
As for the documentation: I suggest adding a default for RealTimeSignalProcessor to settings.py along with the comment to replace it with a cron job if the load becomes to high.
But this RealTimeSignalProcessor really should be fairly efficient since it does not produce any database IO.
This really should not cause too much load since only the new emails are processed and emails are (mostly) short. In my opinion it is the sane default for most cases. One can always comment the line in settings.py. This should probably be documented in mailman-suite?
All of this is covered by the existing tests.
Concerning the commented update_index calls: This is handled by the SignalProcessor.
Yes I checked: we do not need migrations. All the fields are and were CharField(max_length=7).
It was last updated in 2016 and a lot has changed since then.
My main point is that it's only used in one place for one specific view to limit ajax requests.
Apparently not. gitlab won't update the MR with my squashed history ..
Yes -- sorry about that. But the changes are somewhat related at least..
The "obsolete" part refers to 9788e541 ;-)