Giter VIP home page Giter VIP logo

hexirp-hakyll's Introduction

hexirp-hakyll

hexirp-hakyll is static web site generator libraries in Haskell for Hexirp.

hexirp-hakyll は hakyll をフォークした静的ウェブサイト生成プログラムのライブラリ群である。このライブラリは Hexirp が自分で利用するために制作している。

サポートしているGHCについて

hexirp-hexyll は複数のGHCの下でのビルドをサポートしている。現時点では、それらは GHC-8.4.x と GHC-8.6.x のみである。しかし、のちに GHC-8.8.x へのサポートを追加する予定がある。

ここで複数のGHCをサポートするだけではなく、依存ライブラリについて十分に広い範囲のバージョンをサポートする必要がある。この二つの要請を満たせる方法を私は検討した。その結果、 stack を使い、複数の resolver でビルドする方法を選択した。

checked:

  • lts-12.26 (GHC-8.4.4)
  • lts-13.30 (GHC-8.6.5)

それぞれのライブラリについて

ここで hexirp-hakyll は長いため hexyll と略している。ライブラリを分割するわけは、ビルド時のメモリを削減するためと、コピーレフトライセンスを適用する範囲をなるべく減らすためである。

hexyll-core

hexyll の基盤部分を記述しているパッケージである。例えば Route や Rules や Compiler などの定義を含む。ライセンスは Apache-2.0 である。

hexyll

hexyll の本体であり Compiler や Template などの具体的な実装や、ルールなどのDSLから最終的なプログラムを構成する関数を含む。ライセンスは Apache-2.0 である。

hexyll-pandoc

hexyll の pandoc に依存する部分を切り出したパッケージである。もっとも重要なのは pandoc による Compiler の実装を含むことであろう。ライセンスは GPL-2.0-or-later である。

依存ライブラリのバージョン指定について

依存ライブラリのバージョンの指定は、下限も上限も厳密に行う。それは base も例外ではなく、全てのライブラリにバージョンの上限が設定されている。それは、破壊的変更が発生する可能性があるバージョン未満と指定している。

これの例外が、 hexirp-hakyll 内での依存関係である。そのバージョン指定はさらに厳しく、パッチバージョンの変更しか許容しない。例えば、 hexyll-0.1.0.0hexyll-core == 0.1.0.* というバージョン指定を持つ。

テストについて

テストは複数の種類に分けて行っている。すなわち、単体テスト (hspec) とユニットテスト (tasty) とドキュメントテスト (doctest) である。

ライブラリを利用するときの注意について

ファイルパスは filepath パッケージなどを使って出来るだけパス区切りがOSに依存しないようにするべきである。しかし、それが出来ない場合はスラッシュによる区切りを使うべきである。それは Posix 環境ではバックスラッシュが使えないのに対して Windows 環境ではスラッシュも使えるためである。

ライセンスについて

全体には Apache-2.0 を適用しているが、個々のパッケージでは違うライセンスが適用されていることがあるので注意するようにしてほしい。もちろん、個々のパッケージのライセンスの方が優先される。

特に pandoc 関連はコピーレフトライセンス、つまり GPL になっているので注意してほしい。

ライセンスの選択について

hexirp-hakyll は hakyllf2778e12046eb5f5eb4d377669b94b13dffc24fb でクローンしたものである。

元々の hakyll は The 3-Clause BSD License で公開されていた。

しかし、 hakyll にはグレーな部分がある。それは GNU General Public License version 2 or later でライセンスされている pandoc に依存しているのに、本体を The 3-Clause BSD License でライセンスしていることだ。完全な違反でもない訳は、 pandoc に依存するかどうかはビルド時のフラグによって決定されるからだ。

そのため、 hexirp-hakyll は明瞭にするために、 pandoc に依存する部分を別のパッケージに分離し、 GNU General Public License version 3 or later でライセンスしている。

pandoc のライセンスについて

事はそう単純ではなく、 pandoc は GitHub に上げられているリポジトリでは COPYRIGHT で GNU General Public License version 2 or later としてライセンスされている。その一方で Hackage では COPYING.md を参照して GNU General Public License version 2 としてライセンスされている、と表示されている。

私は Hackage を通して使う以上、それでの記述に従うべきと考える。しかし、問題なのは Hackage で配布される package のソースコードで COPYRIGHT が含まれるかどうかだ。どういうライセンスが適用されるかは、最終的にソースコードに同梱されている説明によって決められるべきであるからだ。そして、 Hackage で配布される package には COPYRIGHT が含まれていた。

そのため、私は pandoc のライセンスを GNU General Public License version 2 or later として解釈している。

サンプルについて

リポジトリについているサンプルはないが、もともと自分で使うために作っているものなので、自分のブログで使用する予定である。

やっていけないことについて

実行中に provider ディレクトリや store ディレクトリなどの内容が変化することは全く考慮していない。よってそのようなことが起きないようにしなければならない。

hexirp-hakyll's People

Contributors

athas avatar beastaugh avatar bergmark avatar bergus avatar chrisdotcode avatar christopheryoung avatar crodjer avatar eriknstevenson avatar felixonmars avatar gwern avatar hexirp avatar ian-ross avatar jaspervdj avatar juhp avatar krsch avatar lortabac avatar mcmtroffaes avatar mgsloan avatar nagisa avatar nickie avatar nicolerauch avatar piyush-kurur avatar raindev avatar regisfoucault avatar samgd avatar seschwar avatar sol avatar sphynx avatar stoltene2 avatar uu1101 avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar

hexirp-hakyll's Issues

全体をリファクタリングする

#25 にこれまでの情報はある。

このリファクタリングの過程では他の様々な issue が統合されて解決される。

  1. #12
  2. #15
  3. #19
  4. #25
  5. #37
  6. #48

hexyll-core (2019/12/13)

モジュールのコンパイル順
hexyll-core  > [ 1 of 30] Compiling Data.List.Hexyll
hexyll-core  > [ 2 of 30] Compiling Data.Yaml.Hexyll
hexyll-core  > [ 3 of 30] Compiling Hexyll.Core.Configuration
hexyll-core  > [ 4 of 30] Compiling Hexyll.Core.Identifier
hexyll-core  > [ 5 of 30] Compiling Hexyll.Core.Identifier.Pattern.Internal
hexyll-core  > [ 6 of 30] Compiling Hexyll.Core.Identifier.Pattern
hexyll-core  > [ 7 of 30] Compiling Hexyll.Core.Dependencies
hexyll-core  > [ 8 of 30] Compiling Hexyll.Core.Logger
hexyll-core  > [ 9 of 30] Compiling Hexyll.Core.Metadata
hexyll-core  > [10 of 30] Compiling Hexyll.Core.Store
hexyll-core  > [11 of 30] Compiling Hexyll.Core.Util.File
hexyll-core  > [12 of 30] Compiling Hexyll.Core.Provider.Internal
hexyll-core  > [13 of 30] Compiling Hexyll.Core.Provider.Metadata
hexyll-core  > [14 of 30] Compiling Hexyll.Core.Provider.MetadataCache
hexyll-core  > [15 of 30] Compiling Hexyll.Core.Provider
hexyll-core  > [16 of 30] Compiling Hexyll.Core.Util.Parser
hexyll-core  > [17 of 30] Compiling Hexyll.Core.Util.String
hexyll-core  > [18 of 30] Compiling Hexyll.Core.Routes
hexyll-core  > [19 of 30] Compiling Hexyll.Core.Compiler.Internal
hexyll-core  > [20 of 30] Compiling Hexyll.Core.Item
hexyll-core  > [21 of 30] Compiling Hexyll.Core.Compiler.Require
hexyll-core  > [22 of 30] Compiling Hexyll.Core.Compiler
hexyll-core  > [23 of 30] Compiling Hexyll.Core.UnixFilter
hexyll-core  > [24 of 30] Compiling Hexyll.Core.Writable
hexyll-core  > [25 of 30] Compiling Hexyll.Core.Item.SomeItem
hexyll-core  > [26 of 30] Compiling Hexyll.Core.Rules.Internal
hexyll-core  > [27 of 30] Compiling Hexyll.Core.Runtime
hexyll-core  > [28 of 30] Compiling Hexyll.Core.Rules
hexyll-core  > [29 of 30] Compiling Hexyll.Core.File
hexyll-core  > [30 of 30] Compiling Paths_hexyll_core

この順番に従ってリファクタリングを行っていく。

Internal パッケージの必要性

現時点では Hexyll.Core.IdentifiergetIdentVersionsetIdentVersion を隠す必要があると思われる。また Hexyll.Core.Identifier.Pattern にも隠す必要があると思われるものがたくさんある。

cryptonite へ移行する

cryptohash は非推奨になっていて、次のパッケージとして指定されているのが cryptonite である。

依存関係を刈り込む

$ stack dot hexyll-core --external | wc -m
9741

$ stack dot hexyll --external | wc -m
17089

$ stack dot hexyll-pandoc --external | wc -m
27228

絶対に、分割したことによって必要がなくなった依存関係があるはずである。

修正の Hakyll への逆輸入

できるのは以下のこと。

  • stack.yaml の設定の整理
  • GHC-8.4 でビルドできるようにする
  • cryptonite へ移行する

ライブラリを分割する

以前にコンパイルのためのメモリが不足して失敗したことがある。なので Hakyll.Core 以下のモジュールを含む hakyll-core と Hakyll 以下のモジュールを含む hakyll に分割してみたらどうか。

Hexyll.Core.Identifier.Pattern をリファクタリングする

きちんとした Monoid になっていない、そもそも DSL の形が気に入らない、ベースに regex-tdfa を採用している、など気に入らない所がいっぱいある。

言語拡張も Internal モジュールを統合したので必要なくなった。

古いライブラリに対応するためのコードを削除する

--------------------------------------------------------------------------------
#if MIN_VERSION_base(4,9,0)
instance Semigroup CheckerWrite where
(<>) (CheckerWrite f1 o1) (CheckerWrite f2 o2) =
CheckerWrite (f1 + f2) (o1 + o2)
instance Monoid CheckerWrite where
mempty = CheckerWrite 0 0
mappend = (<>)
#else
instance Monoid CheckerWrite where
mempty = CheckerWrite 0 0
mappend (CheckerWrite f1 o1) (CheckerWrite f2 o2) =
CheckerWrite (f1 + f2) (o1 + o2)
#endif

例えばここのCPPとか。というか、現在では GHC-8.6 (base-4.12) にしか対応していないのに、こういうコードが残っているのにかなり歪さを感じる。

mason を使えないか

mason は早いらしい。 blaze-builder と blaze-html の代替に使えないか。ただし blazing がなになのか分かってないので使えないかもしれない。

deploy 機能を削除する

deploy をするためのコマンドを文字列でここに書いてね! ってちょっと直接過ぎてアプリの内部でやる意味なくない?

後、デプロイするための処理をここで書いてね。 ./site deploy でそのまま実行されるからね! もちょっとひどくない?

サンプルを削除する

私にとっては不要であるため。同時に lib フォルダを src フォルダに移動させる。

Hexyll.Core.Identifier.Pattern.Internal をリファクタリングする

ここは Pattern の DSL が定義されている。 regex-applicative とか glob パッケージを読みながらどうしてくれようかと考えていた。

だが、コメントには、「 CPP を使いたいけどコメントと兼ね合いがうまくいかないからモジュールを分けたんやで」と書いてあった。 CPP を使っている部分はこの前に削除した。うん。統合で問題ないか。

ビルドのフラグを見直しする

ビルドのフラグを使うと、考慮しなければならない場合が乗算的に増えるので。なくしたり、パッケージを分離したりで消していきたい。

部分関数の削除

Hexyll.Core.IdentifierfromFilePath が部分関数になっているので消そう。

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.