2021-07-08 16:22:44 +03:00
|
|
|
# SPDX-FileCopyrightText: 2018-2021 Serokell <https://serokell.io>
|
2019-12-18 17:18:55 +03:00
|
|
|
#
|
|
|
|
# SPDX-License-Identifier: MPL-2.0
|
|
|
|
|
2020-05-15 19:22:24 +03:00
|
|
|
spec-version: 0.31.0
|
|
|
|
|
2020-01-13 15:58:14 +03:00
|
|
|
name: xrefcheck
|
2021-11-09 14:50:13 +03:00
|
|
|
version: 0.2
|
2020-01-13 15:58:14 +03:00
|
|
|
github: serokell/xrefcheck
|
2019-12-18 17:11:24 +03:00
|
|
|
license: MPL-2.0
|
|
|
|
license-file: LICENSE
|
|
|
|
author: Kostya Ivanov, Serokell
|
|
|
|
maintainer: Serokell <hi@serokell.io>
|
|
|
|
copyright: 2018-2019 Serokell <https://serokell.io>
|
2021-07-08 16:22:44 +03:00
|
|
|
description: Please see the README on GitHub at <https://github.com/serokell/xrefcheck#readme>
|
2018-10-11 00:15:08 +03:00
|
|
|
|
|
|
|
extra-source-files:
|
2021-07-08 16:22:44 +03:00
|
|
|
- README.md
|
|
|
|
- CHANGES.md
|
2018-10-11 00:15:08 +03:00
|
|
|
|
|
|
|
default-extensions:
|
|
|
|
- AllowAmbiguousTypes
|
|
|
|
- BangPatterns
|
2022-07-07 16:22:28 +03:00
|
|
|
- BlockArguments
|
2018-10-11 00:15:08 +03:00
|
|
|
- ConstraintKinds
|
|
|
|
- DataKinds
|
|
|
|
- DefaultSignatures
|
|
|
|
- DeriveDataTypeable
|
|
|
|
- DeriveGeneric
|
2021-10-20 14:37:05 +03:00
|
|
|
- DerivingStrategies
|
2018-10-11 00:15:08 +03:00
|
|
|
- FlexibleContexts
|
|
|
|
- FlexibleInstances
|
|
|
|
- FunctionalDependencies
|
|
|
|
- GeneralizedNewtypeDeriving
|
2021-07-26 11:05:00 +03:00
|
|
|
- ImportQualifiedPost
|
2018-10-11 00:15:08 +03:00
|
|
|
- LambdaCase
|
|
|
|
- MultiParamTypeClasses
|
|
|
|
- MultiWayIf
|
|
|
|
- NamedFieldPuns
|
2021-07-26 11:00:21 +03:00
|
|
|
- NoImplicitPrelude
|
2018-10-11 00:15:08 +03:00
|
|
|
- OverloadedStrings
|
|
|
|
- RankNTypes
|
|
|
|
- RecordWildCards
|
|
|
|
- ScopedTypeVariables
|
|
|
|
- StandaloneDeriving
|
|
|
|
- TemplateHaskell
|
|
|
|
- TupleSections
|
|
|
|
- TypeFamilies
|
|
|
|
- UndecidableInstances
|
|
|
|
- ViewPatterns
|
|
|
|
- TypeApplications
|
|
|
|
- TypeOperators
|
|
|
|
|
|
|
|
ghc-options:
|
2022-07-08 18:08:25 +03:00
|
|
|
- -Weverything
|
2019-03-12 16:29:15 +03:00
|
|
|
- -Wincomplete-record-updates
|
2020-11-10 23:38:28 +03:00
|
|
|
- -Wincomplete-uni-patterns
|
2021-11-04 17:41:18 +03:00
|
|
|
- -Wmissing-deriving-strategies
|
2022-07-08 18:08:25 +03:00
|
|
|
- -Wno-missing-safe-haskell-mode
|
|
|
|
- -Wno-unsafe
|
|
|
|
- -Wno-missing-import-lists
|
|
|
|
- -Wno-missing-local-signatures
|
|
|
|
- -Wno-missing-export-lists
|
|
|
|
- -Wno-all-missed-specialisations
|
|
|
|
- -Wno-prepositive-qualified-module
|
|
|
|
- -Wno-monomorphism-restriction
|
2018-10-11 00:15:08 +03:00
|
|
|
|
|
|
|
dependencies:
|
2021-07-26 11:00:21 +03:00
|
|
|
- base
|
2018-10-11 00:15:08 +03:00
|
|
|
|
|
|
|
library:
|
|
|
|
source-dirs: src
|
|
|
|
|
2020-05-16 16:02:38 +03:00
|
|
|
generated-other-modules:
|
2021-07-08 16:22:44 +03:00
|
|
|
- Paths_xrefcheck
|
2020-05-16 16:02:38 +03:00
|
|
|
|
2022-07-08 18:08:25 +03:00
|
|
|
dependencies:
|
|
|
|
- aeson
|
|
|
|
- aeson-casing
|
|
|
|
- async
|
|
|
|
- bytestring
|
|
|
|
- containers
|
|
|
|
- cmark-gfm
|
|
|
|
- data-default
|
|
|
|
- directory-tree
|
|
|
|
- directory
|
|
|
|
- dlist
|
|
|
|
- filepath
|
|
|
|
- raw-strings-qq
|
|
|
|
- fmt
|
|
|
|
- ftp-client
|
|
|
|
- Glob
|
|
|
|
- http-client
|
|
|
|
- http-types
|
|
|
|
- lens
|
|
|
|
- pretty-terminal
|
|
|
|
- modern-uri
|
|
|
|
- mtl
|
|
|
|
- o-clock
|
|
|
|
- optparse-applicative
|
|
|
|
- regex-tdfa
|
|
|
|
- req
|
|
|
|
- roman-numerals
|
|
|
|
- text
|
|
|
|
- text-metrics
|
|
|
|
- th-lift-instances
|
[#31] Handle the "429 too many requests" errors
Problem: The current version of xrefcheck handles the HTTP responses
with the 429 status code just like every other error, when it is
possible to try and eliminate the occurrences of such errors within the
program itself.
Solution: Each time the result of performing a request on a given link
is a 429 error, retrieve the Retry-After information, describing the
delay (in seconds), from the headers of the HTTP response, or,
alternatively, use a configurable default value if the Retry-After
header is absent, and rerun the request after an amount of time
described by the said value had passed. Only after the number of retries
had reached its limiting value, which, as of right now, is not
configurable and is hardcoded, is when the 429 error is converted into
becoming 'unfixable', and any further attempts to remove the error are
terminated.
Additionally, the progress bar has been upgraded and the following
elements are supplied:
1. an extra color -- Blue -- indicating the errors that might get
eliminated during the verification;
2. a timer with the number of seconds left to wait for the restart of
the request; if, during the verification, a new 429 error had emerged
with the new Retry-After value being greater than or equal to the
elapsed time, the timer is immediately updated with that value and
begins ticking down each second from scratch.
2021-10-22 01:00:18 +03:00
|
|
|
- time
|
2022-07-08 18:08:25 +03:00
|
|
|
- universum
|
|
|
|
- yaml
|
|
|
|
|
2018-10-11 00:15:08 +03:00
|
|
|
executables:
|
2020-01-13 15:58:14 +03:00
|
|
|
xrefcheck:
|
2021-07-08 16:22:44 +03:00
|
|
|
main: Main.hs
|
|
|
|
source-dirs: exec
|
2020-05-16 16:02:38 +03:00
|
|
|
generated-other-modules:
|
2021-07-08 16:22:44 +03:00
|
|
|
- Paths_xrefcheck
|
2018-10-11 00:15:08 +03:00
|
|
|
ghc-options:
|
2021-07-08 16:22:44 +03:00
|
|
|
- -threaded
|
|
|
|
- -rtsopts
|
|
|
|
- -with-rtsopts=-N
|
|
|
|
- -O2
|
2018-10-11 00:15:08 +03:00
|
|
|
dependencies:
|
2021-07-08 16:22:44 +03:00
|
|
|
- xrefcheck
|
2022-07-08 18:08:25 +03:00
|
|
|
- bytestring
|
|
|
|
- universum
|
|
|
|
- with-utf8
|
2019-03-11 17:16:06 +03:00
|
|
|
|
|
|
|
tests:
|
2020-01-13 15:58:14 +03:00
|
|
|
xrefcheck-tests:
|
2021-07-08 16:22:44 +03:00
|
|
|
main: Main.hs
|
|
|
|
source-dirs: tests
|
2020-05-16 16:02:38 +03:00
|
|
|
generated-other-modules:
|
2021-07-08 16:22:44 +03:00
|
|
|
- Paths_xrefcheck
|
2019-03-11 17:16:06 +03:00
|
|
|
dependencies:
|
[#31] Handle the "429 too many requests" errors
Problem: The current version of xrefcheck handles the HTTP responses
with the 429 status code just like every other error, when it is
possible to try and eliminate the occurrences of such errors within the
program itself.
Solution: Each time the result of performing a request on a given link
is a 429 error, retrieve the Retry-After information, describing the
delay (in seconds), from the headers of the HTTP response, or,
alternatively, use a configurable default value if the Retry-After
header is absent, and rerun the request after an amount of time
described by the said value had passed. Only after the number of retries
had reached its limiting value, which, as of right now, is not
configurable and is hardcoded, is when the 429 error is converted into
becoming 'unfixable', and any further attempts to remove the error are
terminated.
Additionally, the progress bar has been upgraded and the following
elements are supplied:
1. an extra color -- Blue -- indicating the errors that might get
eliminated during the verification;
2. a timer with the number of seconds left to wait for the restart of
the request; if, during the verification, a new 429 error had emerged
with the new Retry-After value being greater than or equal to the
elapsed time, the timer is immediately updated with that value and
begins ticking down each second from scratch.
2021-10-22 01:00:18 +03:00
|
|
|
- case-insensitive
|
|
|
|
- containers
|
2021-07-08 16:22:44 +03:00
|
|
|
- firefly
|
|
|
|
- hspec
|
2022-07-07 15:09:34 +03:00
|
|
|
- hspec-expectations
|
2021-07-08 16:22:44 +03:00
|
|
|
- QuickCheck
|
|
|
|
- xrefcheck
|
2022-07-08 18:08:25 +03:00
|
|
|
- bytestring
|
|
|
|
- directory
|
|
|
|
- fmt
|
|
|
|
- http-types
|
|
|
|
- HUnit
|
[#31] Handle the "429 too many requests" errors
Problem: The current version of xrefcheck handles the HTTP responses
with the 429 status code just like every other error, when it is
possible to try and eliminate the occurrences of such errors within the
program itself.
Solution: Each time the result of performing a request on a given link
is a 429 error, retrieve the Retry-After information, describing the
delay (in seconds), from the headers of the HTTP response, or,
alternatively, use a configurable default value if the Retry-After
header is absent, and rerun the request after an amount of time
described by the said value had passed. Only after the number of retries
had reached its limiting value, which, as of right now, is not
configurable and is hardcoded, is when the 429 error is converted into
becoming 'unfixable', and any further attempts to remove the error are
terminated.
Additionally, the progress bar has been upgraded and the following
elements are supplied:
1. an extra color -- Blue -- indicating the errors that might get
eliminated during the verification;
2. a timer with the number of seconds left to wait for the restart of
the request; if, during the verification, a new 429 error had emerged
with the new Retry-After value being greater than or equal to the
elapsed time, the timer is immediately updated with that value and
begins ticking down each second from scratch.
2021-10-22 01:00:18 +03:00
|
|
|
- o-clock
|
2022-07-08 18:08:25 +03:00
|
|
|
- regex-tdfa
|
[#31] Handle the "429 too many requests" errors
Problem: The current version of xrefcheck handles the HTTP responses
with the 429 status code just like every other error, when it is
possible to try and eliminate the occurrences of such errors within the
program itself.
Solution: Each time the result of performing a request on a given link
is a 429 error, retrieve the Retry-After information, describing the
delay (in seconds), from the headers of the HTTP response, or,
alternatively, use a configurable default value if the Retry-After
header is absent, and rerun the request after an amount of time
described by the said value had passed. Only after the number of retries
had reached its limiting value, which, as of right now, is not
configurable and is hardcoded, is when the 429 error is converted into
becoming 'unfixable', and any further attempts to remove the error are
terminated.
Additionally, the progress bar has been upgraded and the following
elements are supplied:
1. an extra color -- Blue -- indicating the errors that might get
eliminated during the verification;
2. a timer with the number of seconds left to wait for the restart of
the request; if, during the verification, a new 429 error had emerged
with the new Retry-After value being greater than or equal to the
elapsed time, the timer is immediately updated with that value and
begins ticking down each second from scratch.
2021-10-22 01:00:18 +03:00
|
|
|
- time
|
2022-07-08 18:08:25 +03:00
|
|
|
- universum
|
|
|
|
- yaml
|
2019-12-04 18:13:53 +03:00
|
|
|
build-tools:
|
2021-07-08 16:22:44 +03:00
|
|
|
- hspec-discover
|
|
|
|
|
|
|
|
links-tests:
|
|
|
|
main: Main.hs
|
|
|
|
source-dirs: links-tests
|
|
|
|
build-tools: tasty-discover:tasty-discover
|
|
|
|
generated-other-modules:
|
|
|
|
- Paths_xrefcheck
|
|
|
|
dependencies:
|
|
|
|
- optparse-applicative
|
|
|
|
- tagged
|
|
|
|
- tasty
|
|
|
|
- tasty-hunit
|
|
|
|
- xrefcheck
|
2022-07-08 18:08:25 +03:00
|
|
|
- universum
|