Start refactoring pytroll schedule

.bandit

@@ -0,0 +1,2 @@
+[bandit]
+exclude: trollsched/version.py,versioneer.py,trollsched/tests

.github/workflows/ci.yaml

@@ -21,7 +21,7 @@ jobs:
           python-version: ${{ matrix.python-version }}
       - name: Install dependencies
         run: |
-          pip install -U pytest pytest-cov numpy pyresample pyorbital six pyyaml
+          pip install -U pytest pytest-cov numpy pyresample pyorbital six pyyaml defusedxml
       - name: Install pytroll-collectors
         run: |
           pip install --no-deps -e .

.gitignore

@@ -34,3 +34,9 @@ nosetests.xml
 .mr.developer.cfg
 .project
 .pydevproject
+
+tmp
+.idea
+.vscode
+.ropeproject
+*~

.pre-commit-config.yaml

@@ -0,0 +1,20 @@
+exclude: '^$'
+fail_fast: false
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.4.0
+    hooks:
+      - id: trailing-whitespace
+      - id: end-of-file-fixer
+      - id: check-yaml
+        args: [--unsafe]
+  - repo: https://github.com/charliermarsh/ruff-pre-commit
+    # Ruff version.
+    rev: 'v0.0.247'
+    hooks:
+      - id: ruff
+        args: [--fix, --exit-non-zero-on-fix]
+ci:
+  # To trigger manually, comment on a pull request with "pre-commit.ci autofix"
+  autofix_prs: false
+  skip: [bandit]

docs/about.rst

@@ -5,49 +5,49 @@ About PyTroll-Schedule
 
 Case of One Receiving Station
 -----------------------------
-In the case of a single station, the procedure of scheduling is quite 
+In the case of a single station, the procedure of scheduling is quite
 straightforward. However, let us describe it in detail here, such that the
-background will be set for the more complex case of multiple reception station 
+background will be set for the more complex case of multiple reception station
 reception scheduling.
 
-The first step to compute the schedule, is to know which satellites of interest 
-are going to be rising above the horizon during the duration of the schedule. 
-In order to find such cases, we retrieve the orbital information for each 
-satellite of interest and apply orbit prediction using the aiaa sgp4 algorithm 
-(ref). In practice, we use norad tle files (ref) as orbital elements, and the 
-python implementation of the sgp4 algorithm provided in pyorbital (ref). From 
-this, we then obtain a list of the coming overpasses for the station. We define 
-an overpass as a risetime and fall time for a given satellite, during which it 
+The first step to compute the schedule, is to know which satellites of interest
+are going to be rising above the horizon during the duration of the schedule.
+In order to find such cases, we retrieve the orbital information for each
+satellite of interest and apply orbit prediction using the aiaa sgp4 algorithm
+(ref). In practice, we use norad tle files (ref) as orbital elements, and the
+python implementation of the sgp4 algorithm provided in pyorbital (ref). From
+this, we then obtain a list of the coming overpasses for the station. We define
+an overpass as a risetime and fall time for a given satellite, during which it
 will be within reception reach of the station.
 
-Now, we have to find the possible schedules for the station. The set of all 
-overpasses gives us all the reception possibilities for the station. However, 
-many of them will be in conflict with at least one other overpass and will be 
-a concurrent to the reception race. We say that two overpasses conflict when 
-the risetime dog one of them is comprised within the view time of the second. 
-In case of conflicts, the scheduling algorithm has to choose one or the other 
-overpass. However, in the case of several overpasses conflicting sequentially, 
-we have to find the possible paths through the conflicting zone. In order to do 
+Now, we have to find the possible schedules for the station. The set of all
+overpasses gives us all the reception possibilities for the station. However,
+many of them will be in conflict with at least one other overpass and will be
+a concurrent to the reception race. We say that two overpasses conflict when
+the risetime dog one of them is comprised within the view time of the second.
+In case of conflicts, the scheduling algorithm has to choose one or the other
+overpass. However, in the case of several overpasses conflicting sequentially,
+we have to find the possible paths through the conflicting zone. In order to do
 that, we will use graph theory algorithms.
 
-We define the graph of the conflicting zone with overpasses as vertices and 
-create an edge between two conflicting overpasses. To find the possible 
-non-conflicting combinations in this graph is actually searching for maximal 
-cliques in the complementary graph, for which we use the Bron-Kerbosch 
+We define the graph of the conflicting zone with overpasses as vertices and
+create an edge between two conflicting overpasses. To find the possible
+non-conflicting combinations in this graph is actually searching for maximal
+cliques in the complementary graph, for which we use the Bron-Kerbosch
 algorithm.
 #illustration click
 
 we obtain thus groups of passes that are not conflicting in the time frame.
-The next step is to find the optimal list of non conflicting passes under the 
+The next step is to find the optimal list of non conflicting passes under the
 duration on the schedule.
 
 Cases of Connected Stations
 ---------------------------
-There are several ways to computate schedules for connected stations, two are
+There are several ways to compute schedules for connected stations, two are
 implemented in this program.
 
 Several points should be considered:
-* Technical equipement, reception of L-band, Ku-band, X-band?
+* Technical equipment, reception of L-band, Ku-band, X-band?
 * Geographic location, nearby or large distance between?
 
 "Master-Slave" Operation
@@ -58,26 +58,26 @@ other, with similar technical systems.
 In this case a schedule for one, namely the "master" station, would be computed,
 as if it were only this one station.
 
-In a second step this schedule plan is used as a substraction list when 
+In a second step this schedule plan is used as a subtraction list when
 computing the schedule for the second, the "slave" station.
 
 Co-operating Stations
 *********************
 A mode of co-operating stations can consider the distance between different
-geographical locations and differences in technical equipement, most notable
+geographical locations and differences in technical equipment, most notable
 different reception capabilities (X- & L-band vs. L-band).
 
-In this case, each station defines a time span requirement for each pass. Then, 
-if a connected station can fulfil this requirement and is scheduling the same 
-pass, we can say that the stations are redundant. To avoid such redundancy, we 
-can define ways to synchronise the schedule to optimise the intake of data and 
+In this case, each station defines a time span requirement for each pass. Then,
+if a connected station can fulfil this requirement and is scheduling the same
+pass, we can say that the stations are redundant. To avoid such redundancy, we
+can define ways to synchronise the schedule to optimise the intake of data and
 fulfil the pareto condition.
-A simple protocol can be used to perform this: both A and B provide alternatives 
+A simple protocol can be used to perform this: both A and B provide alternatives
 and compute the enhanced score for the schedule including the others pass.
 
-B can delegate the pass only if it can assure that the time span requirement of 
+B can delegate the pass only if it can assure that the time span requirement of
 A is respected.
 
-This operation can be extended to more than two stations, all receiving a 
+This operation can be extended to more than two stations, all receiving a
 single-operation schedule and an individual cooperating-schedule.
 

docs/config.rst

@@ -153,7 +153,7 @@ Stations
 	described below. If no sub-keys are given, the scores from the section
 	``satellites`` are used.
 
-	Alternativly the satellites can be listed as a list, as shown in the
+	Alternatively the satellites can be listed as a list, as shown in the
 	following example for station "nrk". In this case all names refer to the
 	section ``satellites``.
 

docs/usage.rst

@@ -1,14 +1,18 @@
 Usage
 =====
 
+To run the schedule script, it is now compulsory to provide a configuration file
+(see the config section on how these are formed). Command line arguments
+override what is provided in the configuration file.
+
 Usage of the schedule script::
 
 	usage: schedule [-h] [-c CONFIG] [-t TLE] [-l LOG] [-m [MAIL [MAIL ...]]] [-v]
 	                [--lat LAT] [--lon LON] [--alt ALT] [-f FORWARD]
 	                [-s START_TIME] [-d DELAY] [-a AVOID] [--no-aqua-terra-dump]
 	                [--multiproc] [-o OUTPUT_DIR] [-u OUTPUT_URL] [-x] [-r]
 	                [--scisys] [-p] [-g]
-	
+
 	optional arguments:
 	  -h, --help            show this help message and exit
 	  -c CONFIG, --config CONFIG
@@ -18,10 +22,10 @@ Usage of the schedule script::
 	  -m [MAIL [MAIL ...]], --mail [MAIL [MAIL ...]]
 	                        mail address(es) to send error messages to.
 	  -v, --verbose         print debug messages too
-	
+
 	start-parameter:
 	  (or set values in the configuration file)
-	
+
 	  --lat LAT             Latitude, degrees north
 	  --lon LON             Longitude, degrees east
 	  --alt ALT             Altitude, km
@@ -32,18 +36,18 @@ Usage of the schedule script::
 	  -d DELAY, --delay DELAY
 	                        delay (in seconds) needed between two consecutive
 	                        passes (60 seconds by default)
-	
+
 	special:
 	  (additional parameter changing behaviour)
-	
+
 	  -a AVOID, --avoid AVOID
 	                        xml request file with passes to avoid
 	  --no-aqua-terra-dump  do not consider Aqua/Terra-dumps
 	  --multiproc           use multiple parallel processes
-	
+
 	output:
 	  (file pattern are taken from configuration file)
-	
+
 	  -o OUTPUT_DIR, --output-dir OUTPUT_DIR
 	                        where to put generated files
 	  -u OUTPUT_URL, --output-url OUTPUT_URL