Solubility-Aware Protein Binding Peptide Design Using AlphaFoldがPublishされました
はじめに
2022/07/07に自身がこれまで取り組んできた研究成果をまとめた論文がBiomedicines誌に掲載されました。
Kosugi, T.; Ohue, M. Solubility-Aware Protein Binding Peptide Design Using AlphaFold. Biomedicines 2022, 10, 1626. https://doi.org/10.3390/biomedicines10071626
一体どんなことをやったのかということを、ざっとFigureをベース解説していきたいと思います。（ちょっと論文調の感じで分かりづらかったらTwitterで質問してください。）
ざっくりというと、AlphaFold2のペプチドドッキングにおいて、AlphaFold2の信頼性指標のpLDDTやPAEやdistogramだけでなく、さらにアミノ酸の溶解度指標による損失関数を作成し、backpropさせることで、ターゲットタンパク質に結合が期待できかつ脂溶性が高すぎないようなペプチド配列をデザインする技術を開発しました。
この論文はCC BY 4.0として、内容の翻訳解説やFigureを転載しています。
論文概要
近年、新しいタンパク質-タンパク質相互作用（PPI）が発見されているものの、PPIは従来のリガンドポケット型等の標的とは異なり、PPI界面は広く、浅いという特徴のため、そのような領域に低分子化合物をモダリティとすることは難しいことが知られています9, 11。ペプチドはPPIを標的とする新しいモダリティですが、計算によって、ターゲットタンパク質に結合し得る適切なペプチド配列を設計することも困難でした。 しかし、2021年AlphaFoldやRoseTTAFoldの開発により29, 30、アミノ酸配列から超高精度にタンパク質構造を予測することが可能となり、その結果、ある立体構造を形成しうる配列をデザインするde novoタンパク質設計が可能になりつつあります33-35, 50。
そのde novoタンパク質設計手法の中でも、私の研究室ではSergey先生が開発を進めている、AlphaFoldを用いたde novoタンパク質設計法であるAfDesign36のbinder hallucinationプロトコルであれば、ターゲットタンパク質に結合し得る適切なペプチド配列を設計することが比較的容易にできるのではないか？と考え、ターゲットタンパク質としてPPIを持つ可能性の高いペプチドを設計しました。しかし，そのペプチドの溶解度はnativeのペプチドに比べると低い傾向にありました。そこで、Hydropathy Indexのようなアミノ酸の溶解度指標 (solubility index)を用いて、AfDesignの損失関数に合うように溶解度損失 (solubility loss)を設計し、溶解度を考慮したAfDesignのbinder hallucinationプロトコルを開発しました。
このプロトコルを用いて設計された配列のペプチド溶解度は、solubility lossの重みとともに増加し、さらにsolubility indexの特性を捉えていることが確認でき、さらに、ターゲットタンパク質とペプチドのドッキングによる結合親和性評価によって、この新しいプロトコルの配列は、ランダムまたはnativeの1残基置換の配列よりも高い親和性を持つ傾向がありました。
MDM2/p53を例として、溶解性を制御しながらPPIの界面に結合できるペプチド配列を設計することが可能であることが示されました。
結果詳細
詳細は、論文を読んできただけれたらと思いますが、Figureの流れに合わせて、ポイントだけ。 論文はオープンアクセスなので、論文と照らしてみていただければと思います。
- 溶解度を考慮したペプチドデザインをするために、３つのアミノ酸のsolubility index41-43を用いて、solubility lossを設計しAfDesignに導入しました（Figure 1）（3つのindexで検討したのは比較検討をしたかったから。約40年前に検討されたsolubility indexが適切なのか、それとも近年機械学習で溶解度予測に使われている重みをsolubility indexとしたものが適切なのか等。）
- "開発された当時"のAfDesignのデフォルト設定で、binder hallucinationをMDM2に適用すると、溶解度がnative binding peptide のp53よりも低い傾向でした。そしてその配列群のWeblogoは中央に疎水性・芳香族アミノ酸が集中していることがわかりました。（Figure 2）
- 溶解度を考慮し設計されたペプチド配列の溶解度（logS）は、すべてのsolubility indexにおいて、solubility lossの重みとともに増加し、そのsolubility indexの特徴も捉えていることがわかりました。(Figure 3, Figure 4, Supplementary Table 1-2)
- 溶解度を考慮し設計されたペプチド配列の結合親和性はベンチマークで評価されたAutoDock CrankPep44, 51を用いて計算されました。その結合親和性はsolubility indexによって異なる傾向を示し、特にHydrophobicity Indexは重みの増加とともに、結合親和性が悪くなる傾向が見られました（Figure 5） （エネルギーが低いほど結合親和性が高く、良い。なので分布が左に行くほど結合親和性が高く、良いということです。）
- 溶解度と結合親和性の関係性を調べたところ、Hydrophobicity Indexは溶解度が向上するものの、結合親和性も低下する傾向があり、Hydropathy IndexとSolubility-Weighted Indexに関しては、溶解度が向上しつつ、結合親和性も向上する傾向があありました。特にHydropathy Indexではその傾向が顕著でした。(Figure 6)
最後のFigureに行く前にsupplementary figureの説明に入ります。
- デタラメな配列でも結合親和性が高くなる傾向がある可能性を否定するため、ランダム配列の結合親和性を計算、比較しました。さらに、溶解度を考慮したデザイン配列がnativeのp53配列およびその1残基置換配列の結合親和性を計算、比較しました。ランダム配列の結合親和性の分布は最も低めであり、nativeのp53の１残基置換配列の結合親和性の分布はランダム配列の結合親和性の分布よりは高いものの溶解度を考慮した配列の結合親和性の分布よりは低めでした。（Supplementary Figure 1）
- 溶解度と結合親和性の評価に加え、PyMOLを用いた可視化、DockQを用いたドッキングの評価も行いました。（Supplementary Figure 2）AfDesignのbinder hallucinationプロトコルでSolubility-Weighted Indexをsolubility indexとして設計した配列の中から、p53ペプチド配列よりも高いlogSで結合親和性のが最も高い配列とnativeの立体構造を比較すると、その座標はp53ペプチドとほぼ同じでした。DockQ scoreは0.500で、ペプチドの主鎖原子のRMSDであるLRMSは5.303Å、リガンド間の界面にある残基の重原子のRMSDであるiRMSは2.294Åと算出されました。これはCAPRIのタンパク質-タンパク質ドッキング基準では中程度の品質とされ、AfDesign binder hallucinationプロトコルでSolubility-Weighted Indexをsolubility indexとして設計した配列がMDM2にドッキングする妥当性が示されました。（シアン：p53, マゼンダ：設計配列, 緑・白: MDM2）
実際の設計時におけるsolubility lossのiterationごとの変化を中央値で比べてみると、solubility indexを用いない方が設計時のstageの変化によるlossの変化が少ない。これは，溶解度が低くなりがちな配列の溶解度を最適化することと，最適な複合体を形成しそうなペプチド配列を最適化することのトレードオフといえる可能性がわかりました。（Supplementary Figure S3）
- また、MDM2/p53複合体でだけでなく、βシート同士のPPI事例としてPD-1/PD-L1複合体のPD-1をターゲットタンパク質として、同様にbinderを設計したところ、結合親和性に関してランダム配列とあまり違いがなく、Hydropathy Indexを用いた場合だけランダム配列よりも結合親和性の向上が見られました。（Supplementary Figure S4）
p53 like peptideとして実験的に結合親和性も確認されている超高結合親和性であるPDIQ55を今回の検討と合わせるためにC末端に"N"を付加した配列の溶解度と結合親和性を計算し、フィルタリングし、その中から結合親和性が最も高い配列（我々がデザインした高親和性配列）を用いて、以下の検討を行いました。
フィルタリングの結果、solubility indexを用いなかった場合は配列が残りませんでした。Solubility-Weighted Indexを用いた場合の配列は600個中9個、Hydropathy Indexを用いた場合の配列は600個中90個、Hydrophobicity Indexを用いた場合の配列は600個中2個が残りました。Hydropathy Indexを用いた場の90配列についてWeblogoで可視化すると、PDIQと同様に、6番目と7番目の残基は主に'W'であり、5番目の残基は'Y'である傾向があり、結合親和性を高めると考えられ、C末端とN末端の残基は'E'と'D'の傾向があり、全体的に溶解性を高めている可能性があると考えられました。
- native peptideであるp53 peptide 配列とcompetitorとして我々がデザインした高親和性配列を用いて、近年報告があったAlphaFoldを用いたcompetitive peptide binding prediction49をColabFoldを用いて行いました（20runs x 5models = 100 predictions）。20runsのtop-rank1の全てにおいて、competitorである我々がデザインした高親和性配列の構造がMDM2のPPI結合界面に位置していました。（Supplementary Figure S6）(シアン：競合結合で飛ばされたp53, マゼンダ：我々がデザインした高親和性配列, 緑: MDM2)
- さらに、100predictions中1例を除き、competitorである我々がデザインした高親和性配列のほうがp53 peptide 配列よりもplDDTがやや高い傾向くRMSDが低いという結果になった。（Supplementary Figure S7, Supplementary Table S9）これは、competitorである我々がデザインした高親和性配列のほうがp53 peptide 配列より結合親和性が高いことを示唆しており、これまでの結果と整合性が合うと考えられました。（左側13残基がcompetitorである我々がデザインした高親和性配列、中央はMDM2、右側13残基がp53 peptide配列を示していて、competitorである我々がデザインした高親和性配列のほうがplDDTが高い傾向があることがわかります。更にRMSDとの整合性もありました。）
- そして、最後に、PLIP49を用いて、MDM2/p53の原子間相互作用とMDM2/我々がデザインした高親和性配列の原子間相互作用を比較しました。その結果、MDM2の共通する残基において、いくつかの塩橋・疎水性結合が見られました。MDM2/p53のおける共通の相互作用がColabFoldを用いた設計ペプチドのモデルでも再現されていることが示されました。（Figure 7）
まとめ
本研究では、AfDesignのbinder hallucination protocolをPPI標的ペプチド設計に適用し、ペプチドの配列設計と溶解度の制御の同時最適化を試みました。
- AfDesignの柔軟な損失関数の概念により、その損失関数ににsolubility indexを用いたsolubility lossを加えることで溶解度をコントロールしながら、PPI界面に結合しそうなペプチドを設計することができました。
- ドッキングと競合ペプチド結合予測による結合親和性の評価により、PPIをターゲットタンパク質としたネイティブペプチドの結合親和性よりも高いペプチド配列を設計することができました。
- さらに、ネイティブのMDM2/p53複合体の原子間相互作用と比較した結果、設計したペプチドはMDM2の共通アミノ酸残基とも原子間相互作用を持つことがわかりました。
これらの結果から、本手法はPPIを標的としたペプチドデザインを用いた創薬に役立つ可能性があると考えられます。
コード
論文で用いられている、3つのSolubility index及びその重みを設定しつつ、AfDesignのbinder hallucinationを実行できるコード・Colab用のnotebookはGitHubで公開しています。 github.com
参考文献
上付きの数字は論文に合わせています。とりあえずブログで引用した分は書いておきます。
Shin, W.-H.; Kumazawa, K.; Imai, K.; Hirokawa, T.; Kihara, D. Current challenges and opportunities in designing protein–protein interaction targeted drugs. Adv. Appl. Bioinform. Chem. 2020, 13, 11–25.
Kosugi, T.; Ohue, M. Quantitative Estimate Index for Early-Stage Screening of Compounds Targeting Protein-Protein Interactions. Int. J. Mol. Sci. 2021, 22, 10925.
Jumper, J.; Evans, R.; Pritzel, A.; Green, T.; Figurnov, M.; Ronneberger, O.; Tunyasuvunakool, K.; Bates, R.; Žídek, A.; Potapenko, A.; et al. Highly Accurate Protein Structure Prediction with AlphaFold. Nature 2021, 596, 583–589.
Baek, M.; DiMaio, F.; Anishchenko, I.; Dauparas, J.; Ovchinnikov, S.; Lee, G.R.; Wang, J.; Cong, Q.; Kinch, L.N.; Schaeffer, R.D.; et al. Accurate Prediction of Protein Structures and Interactions Using a Three-Track Neural Network. Science 2021, 373, 871–876.
Anishchenko, I.; Pellock, S.J.; Chidyausiku, T.M.; Ramelot, T.A.; Ovchinnikov, S.; Hao, J.; Bafna, K.; Norn, C.; Kang, A.; Bera, A.K.; et al. De Novo Protein Design by Deep Network Hallucination. Nature 2021, 600, 547–552. [Google Scholar] [CrossRef]
Cao, L.; Coventry, B.; Goreshnik, I.; Huang, B.; Park, J.S.; Jude, K.M.; Marković, I.; Kadam, R.U.; Verschueren, K.H.G.; Verstraete, K.; et al. Design of Protein Binding Proteins from Target Structure Alone. Nature 2022, 605, 551–560. [Google Scholar] [CrossRef] [PubMed]
Jendrusch, M.; Korbel, J.O.; Sadiq, S.K. AlphaDesign: A de Novo Protein Design Framework Based on AlphaFold. bioRxiv 2021.
GitHub, AfDesign (v1.0.2); GitHub: San Francisco, CA, USA, 2022. Available online: https://github.com/sokrypton/ColabDesign/tree/main/af(accessed on 14 March 2022).
Bhandari, B.K.; Gardner, P.P.; Lim, C.S. Solubility-Weighted Index: Fast and Accurate Prediction of Protein Solubility. Bioinformatics 2020, 36, 4691–4698.
Argos, P.; Rao, J.K.M.; Hargrave, P.A. Structural Prediction of Membrane-Bound Proteins. Eur. J. Biochem. 1982, 128, 565–575.
Kyte, J.; Doolittle, R.F. A Simple Method for Displaying the Hydropathic Character of a Protein. J. Mol. Biol. 1982, 157, 105–132.
Zhang, Y.; Sanner, M.F. AutoDock CrankPep: Combining Folding and Docking to Predict Protein–Peptide Complexes. Bioinformatics 2019, 35, 5121–5127.
Adasme, M.F.; Linnemann, K.L.; Bolz, S.N.; Kaiser, F.; Salentin, S.; Haupt, V.J.; Schroeder, M. PLIP 2021: Expanding the Scope of the Protein-Ligand Interaction Profiler to DNA and RNA. Nucleic Acids Res. 2021, 49, W530–W534.
Norn, C.; Wicky, B.I.M.; Juergens, D.; Liu, S.; Kim, D.; Tischer, D.; Koepnick, B.; Anishchenko, I.; Foldit Players; Baker, D.; et al. Protein Sequence Design by Conformational Landscape Optimization. Proc. Natl. Acad. Sci. USA 2021, 118, e2017228118.
Weng, G.; Gao, J.; Wang, Z.; Wang, E.; Hu, X.; Yao, X.; Cao, D.; Hou, T. Comprehensive Evaluation of Fourteen Docking Programs on Protein–Peptide Complexes. J. Chem. Theory Comput. 2020, 16, 3959–3969.
最後に
今回の論文はTwitterでいろんな方に助けていだきました。
ColabFoldをローカルのマシーンで使えるlocalcolabfoldの開発者である森脇先生には、別件で、MSAを再取得する必要がない場合には、a3mを入力するといいよと教えていただきました。ペプチドにはMSAは必要がなく、MDM2のMSAはすでに持っている状態だったので、この入力方法でCompetitive Peptide Binding Predictionsを行いました。
@ddd_ppp_storyさんには原子間相互作用をいい感じに可視化したい時にPLIPというツールを教えてくださいました。最終的にはデザイン配列とp53配列の比較としてmain figureにすることができました。
PLIPとかどうでしょう？https://t.co/4DT9w5LFrK
— Terrari et al. (@ddd_ppp_story) 2022年6月29日
@jvarga92さんにはPyMOLを使ってMDM2でalignしたあとにp53やデザインしたペプチドのRMSDを計算の仕方がいまいちわからなかった時に教えていただきました。こちらも計算結果をSupplementary Table S9に載せることができました。
Do align (or super) just on the receptor chains: 'align obj1 and chain A, obj2 and chain A'. Then, you can calculate rmsd with 'rms_cur obj1 and chain B, obj2 and chain B' https://t.co/HNiByLZr0W
— Varga Julia (@jvarga92) 2022年6月29日
そして、もちろん論文にも記載していますがSergey先生が開発したAfDesignを用いて今回の論文を構成しました。当時はまだTwitter上でもほとんどコミュニケーションをしてはいなかったのですが、今では、更に進化したbinder hallucinationの実装について議論させていただいてます。
ここには挙げきれていない先生方もいらっしゃいますが、本当にありがとうございました。これからもよろしくおねがいします。
【M1】devcontainerを使った、研究コード開発環境の構築
はじめに
これまで、Pythonをベースとした研究コードを作成する際に、pyenvでディレクトリごとにPythonのバージョンや必要なmoduleをinstallして作っていましたが、
共有計算機や別環境で計算を行うことも多く、pyenvがupdateされていて、いい感じに必要なライブラリなどが用意できてないとpyenv install x.x.xといった単順なコマンドがコケることもあり、この際再現性などの観点からもDockerで研究コードを開発するようにしようと思ったのがきっかけです。
（ちなみに、M1のMackBook Proのまっさらな状況で、Homebrewでbrew install pyenvでインストールしてPATH等設定したら挙動することは確認できてますが今回はDockerで環境を作ることに集中します。）
前提
- MacのM1チップ用のDocker Desktopを利用
- 他の多くの計算環境でも使えるようにデフォルトのARM64イメージではなく、x86-64(AMD64)のイメージで行う
- Visual Studio Code](https://code.visualstudio.com/)のdevcontainerを使う（完成物と開発過程のDockerイメージを基本同一で開発したい）
特に最後のdevcontainerの話は、開発物にはformatterやnotebookのモジュールはいらないけれど、開発時にはそのようなモジュールがあると嬉しいみたいなことがあったり、 最近Visual Studio CodeのupdateでRemote - SSHでもdevcontainerを使えるようになったので、ある程度開発が進んでマシーンスペックを上げて共有計算機やクラウドなどで並列計算させたりしつつリモート環境下での開発などの需要のときに、わざわざリモート側で開発物用の環境を作る必要がないということが大きいです。（これまでは、リモートでpyenvやvenvなどを使ってDockerfileのバージョンに合わせ、requirements.txtを使ってほぼ同じ環境っぽい状態にするといった工程が挟まっていたが、それがなくなった。）
【注】他の共有計算機環境があるならそこにRemote −SSH + devcontainerで開発すればいいのでは？って言うこともありますが、本題は新しいMacのM1チップでどこまでできるのかということを意図しています。共有計算機ないけど、M1 MacBook ProがあってDockerでゴニョゴニョしたいという状況が1番優先される前提です。今後利便性も含め、x86-64環境でビルドしたDocker imageをつかってM1のDockerでコンテナ作成、実行などができるかの検証も今後する予定です。
M1という障壁
その他の記事でも言われていますが、M1でなければそんな面倒でもないですが、ローカルの環境がM1のMacBook Proだとチップの違いによりARM64でビルドされていないPythonモジュールはpip installできません。Dockerでもそれは同じで、Dockerで作られるimageがARM64だと同様の現象が起きます。 有名どころのモジュールは対応してくれていますがそんなたくさんないのでM1 用のDoker Desktopはマルチプラットフォームでimageが作成可能なため、AMD64でimageを作ることで、前述の問題を回避します。さらにそのビルドしたimageはx86-64の環境でそのまま使えるということにも繋がります。
対応策
最終的な形はこちらのGitHub レポジトリを見てもらえば良いと思いますが、要所をまとめます。
Dockerfile
- 適当にお好みのPython公式のimageを引っ張ってくる。マイナーバージョンまで指定すればビルドタイミングによるバージョン変更など起きない。
- requirements.txtに研究コードに必要なモジュールをバージョンを指定しておく。
WORKDIRはdocker-compose.ymlのservicesに合わせる 。アプリケーション開発だとappとすることが多いので一旦appとしているが適宜変えて良い。
FROM python:3.7.9 COPY ./requirements.txt /requirements.txt RUN pip install -r /requirements.txt WORKDIR /app
まぁシンプルな感じ
docker-compose.yml
Dockerコマンドが開発ディレクトリをマウントしたり、imageのidを参照するなどすると面倒だし、コマンドが長くなるので、docker-composeを使う。そのため、その設定ファイルであるdocker-compose.ymlが必要
- 最大のポイントはここで
platform: linux/amd64としてプラットフォームを指定し、x86-64(AMD64)のimageが作られるようにする。 - あとは開発ディレクトリをマウントしておく(
.とすることで、docker-compose.ymlがある場所をマウントするということになる。)
version: "3.8" services: app: build: . platform: linux/amd64 volumes: - ./:/app
とりあえずテスト
まずはDockerfileをビルドする。
docker-compose build
とりあえずビルドが終わったら、所定のバージョンがインストールされているか、ご所望のモジュールがインストールされているかなど確認してみる
docker-compose run app python -V # Python 3.7.9 (Dockerfileで指定したversion)
docker-compose run app pip list # Package Version # --------------- -------- # click 7.1.2 # numpy 1.21.5 # pandas 1.3.5 # Pillow 8.4.0 # pip 21.0.1 # python-dateutil 2.8.2 # pytz 2021.3 # QEPPI 0.1.11 # rdkit-pypi 2021.9.3 # setuptools 53.0.0 # six 1.16.0 # wheel 0.36.2
コンテナの中に遊んでもいい。
docker-compose exec app bash
とすれば、コンテナの中に入れるのであとは適宜必要に応じて確認などする。
pythonモジュールの作成
なんか適当に開発モジュールを適当に作る。要するにxxxx.py。
今回テスト的に、py4chemoinformaticsを参考にRDKitのMolToGridImageでsildenafilとvardenafilの構造式をプロットしてくれるコードを書きました。（MolToGridImage.py)
あと、今回の本題とは、ずれますがargparserとしてclickを採用しました。シンプルで結構便利です。
モジュールを動かしてみる
docker-compose run app python -m rdkit_MolToGridImage --output ./data --name test --align True # 上記はargをあえて書いているが、defaultを指定しておけば、 docker-compose run app python -m rdkit_MolToGridImage でも実行可能
単にDockerでPython環境を固定して動かすだけであれば、これで十分だが、Visual Studio Codeのdevcontainerを使って開発したいので、こちらを準備する。
devcontainer
Visual Studio Codeを開いて、左下の><となっているところをクリックして、Add Development Container Configuration Filesっていうのをクリックして、From docker-composeというのを選ぶと、.devcontainerディレクトリができて、devcontainer.jsonとdocker-compose.ymlが生成される。
devcontainer.json
基本自動生成されたままでよいが、使用するPythonは、devcontainerのpythonを指定。/usr/local/bin/pythonで問題ないはず。
今回は、devcontainer上だけで使いたいフォーマッターなどのモジュールをinstallしたり、Visual Studio CodeのExtensionを毎回設定するのは面倒なので、devcontainerを使うときに最初から設定されるようにする。
"settings", "extensions", "postCreateCommand"らへんがそんなところ。
docker-compose.yml
自動生成されたままでOK
詳細はGitHubを参照してもらえばと思います。
devcontainerの起動
上記がおわったら、早速起動してみましょう。左下の><となっているところをクリックして、Open Fold in Containerをクリックすれば、devcontainerがビルドされます。コンテナ作成と追加のモジュールのインストール程度の時間なので、1-2分くらいです。そうすると以下のようになります。
あとは、よしなにこちらで開発をすすめていけばOKです。
Jupyter Notebookについて
Visual Studio Codeは.ipynbファイルを読みこんでノートブックとして動かすことが可能で固定された環境でとても便利ですが、上記の経緯で進めた結果、Notebookの実行でM1固有の問題に直面し、Cellを実行すると、
Failed to start the Kernel. qemu: uncaught target signal 6 (Aborted) - core dumped. View Jupyter log for further details.
となってしまって、実行できませんでした。いろいろ調べましたが現状Jupyter NotebookをVisual Studio Codeで動かすことは、まだ難しそうです。
おわりに
今回は、
- MacのM1チップ用のDocker Desktopを利用して、M1のMacでも特定のPython環境にお好みのモジュールをinstallし研究コードを開発する環境構築方法を示しました。
- また、
docker-composeを使うことで長くなりがちのdockerコマンドを簡略化しました。 docker-composeコマンドを使って、実際のpythonモジュールを動かす方法示しました。- Visual Studio Codeのdevcontainerを使って、完成品の環境と同一のimageを使った状態で開発をすすめる方法を示しました。
残念ながら、Jupyter NotebookをVisual Studio Codeで動かすことができなかったです。今後のupdateを期待したいところです。
【M1】Dockerコマンド補完でハマったのでメモ
はじめに
Apple Silicon (M1)のMacBook ProでDocker Desktopを導入後Dockerコマンドを補完するやり方をこれまでのMacBook Proと同じようにはできなかったので、ドキュメントに書いてある方法などでうまくいかなかった方法や、最終的にできた方法を記します。
ちなみにzshは/bin/zshのものを使っています。
Dockerコマンドの補完機能の設定について
公式にはDocker composeの設定の仕方が書いてある
docs.docker.com
oh-my-zshは使っていないので、
Without oh-my-zsh shellでのやり方を見ると、
mkdir -p ~/.zsh/completion
curl \
-L https://raw.githubusercontent.com/docker/compose/1.29.2/contrib/completion/zsh/_docker-compose \
-o ~/.zsh/completion/_docker-compose
となっているが、このあとの処理を書き加えてもうまく行かない。（結果的にこのcurlしてくるファイルがM1には良くないっぽい）
なんか違う方法はないかと色々調べるとここらへんに行き着く docs.docker.jp
これのM1バージョンで、brewのzshのpathに変更してもだめ（M1の場合のPATHは/opt/homebrew/share/zsh/site-functions/）
etc=/Applications/Docker.app/Contents/Resources/etc ln -s $etc/docker.zsh-completion /opt/homebrew/share/zsh/site-functions/_docker ln -s $etc/docker-compose.zsh-completion /opt/homebrew/share/zsh/site-functions/_docker-compose
とまぁ、色々試した結果、なんだかよくわからんが上記合わせ技で解決。
つまり、１つ目の補完に必要なファイルをcurlで引っ張るのではなく、Docker Desktop for Macに付随している補完スクリプトのシンボリックリンクを貼るようにする。
後半はzshの補完機能を有効にするために.zshrcに記述する。
シェルを一度切って、もう一度立ち上げ、docker[半角スペース]としてtabを押せば以下のようになる
% docker attach -- Attach local standard input, output, and error streams to a running container build -- Build an image from a Dockerfile builder -- Manage builds buildx* -- Docker Buildx (Docker Inc., v0.7.1) commit -- Create a new image from a container's changes compose* -- Docker Compose (Docker Inc., v2.2.1) config -- Manage Docker configs container -- Manage containers ...
docker-compose[半角スペース]としてtabを押せば以下のようになる
% docker-compose build -- Build or rebuild services convert -- Converts the compose file to platform's canonical format cp -- Copy files/folders between a service container and the local filesystem create -- Creates containers for a service. down -- Stop and remove containers, networks events -- Receive real time events from containers. exec -- Execute a command in a running container. images -- List images used by the created containers kill -- Force stop service containers. logs -- View output from containers ls -- List running compose projects ...
補完できている。これで快適Docker生活
おわりに
まだM1でDockerコマンドの補完について書かれているものは見つからなかったので、同じくハマっている人がいたら参考になればと思います。
国際会議IEEE CIBCB2021の論文がPublishされました。
はじめに
2021/10/18に国際会議IEEE CIBCB2021の論文がPublishされました。
ieeexplore.ieee.org
T. Kosugi and M. Ohue, "Quantitative Estimate of Protein-Protein Interaction Targeting Drug-likeness," 2021 IEEE Conference on Computational Intelligence in Bioinformatics and Computational Biology (CIBCB), 2021, pp. 1-8, doi: 10.1109/CIBCB49929.2021.9562931.
論文概要
タンパク質間相互作用（PPI）は最近注目されている創薬の標的です。薬となる化合物を設計する際に、その化合物がPPIを標的にできそうかどうかの度合いを定量的にスコア化する手法はありませんでした。そこで、化合物がPPIを標的にできそうかどうかを定量的にスコア化する手法を開発したという内容になっています。
先に、拡張版のほうがPublishされているので、こちらの方がより詳細に議論されている内容が盛り込まれています。
拡張版を紹介した過去記事は以下です。
QEPPIのコード
論文で用いられている、低分子化合物のPPIを標的にできそう度合いをスコア化した「QEPPI」はGitHubで公開しています。 https://github.com/ohuelab/QEPPI
Bio"Pack"athon2021 #10にて発表しました。
はじめに
先日も報告しましたが、最近論文がPublishされました。
Kosugi T, Ohue M. Quantitative Estimate Index for Early-Stage Screening of Compounds Targeting Protein-Protein Interactions. International Journal of Molecular Sciences. 2021; 22(20):10925. https://doi.org/10.3390/ijms222010925
サラッとした説明は昨日も書きました。 blacktanktop.hatenablog.com
今回の研究で、低分子化合物がタンパク質間相互作用（PPI）を標的にできそうかどうかを定量的にスコア化出来るモジュールQEPPIを開発したので、せっかくだからGitHubにあるだけでなく、研究者がさっと使えるように、pip install QEPPIとできるようにPyPIに登録してみました。自身としては初めての試みだったので、色々と調べながらやったことをまとめます。最初は開発モジュールの概要と紹介です。
面白そう！@biopackathon でパッケージの内容と開発手順を発表しませんか？
— もじゃもじゃのほう (Koki Tsuyuzaki) (@antiplastics) October 4, 2021
また、PyPIに登録した後に、@antiplasticsさんからBio"Pack"athon2021 #10へ参加しませんか？ということで誘っていただき、本日発表を行ってきました。
QEPPIとは
タンパク質は、単体で機能するタンパク質もありますが、タンパク質とタンパク質とが相互作用（Protein-Protein interaction (PPI)）することで特有の機能をします。（例えば、シグナル伝達・転写因子群による転写など）
近年、医薬品の開発において様々な標的の中で注目されているのがこのPPIです。しかしながら従来の標的（単体のタンパク質のリガンドポケット）とは大きく特性が異なるため、従来の指標ではPPIを標的にできそうかどうかを定量的にスコア化することが困難であることがこれまでの研究で知られており、求められています。
そこで私が所属しているラボで、低分子化合物がPPI（タンパク質間相互作用）を標的にできそうな度合いを定量的にスコア化できるQEPPIを開発しました。
低分子化合物がタンパク質間相互作用（PPI）を標的にできそうかどうかを定量的にスコア化した「QEPPI」がを公開しています。https://t.co/XOcSuf57Js
— くろたんく@FullyVaccinated (@black_tank_top) October 4, 2021
Colabでお手軽にためせるので、お手元のPPIを標的としそうな化合物のSMILES を入力してQEPPIスコアを計算してみて下さい。https://t.co/XOcSuf57Js https://t.co/yw6uXsxEF1
開発について
GitHub上での開発
公開しているコードは、QEPPIを計算するモジュールのみですが、実際の開発では、学習（正確にいうと学習ではないので学習みたいな）コードも書いています。基本となる、QEDという従来医薬品における定量指標の論文に記述されている数式をベースにコードに起こして、作成しました。最終的に推論（これまた、正確に言うと推論ではないが推論みたいな）コードを公開したという経緯になります。
PyPIへの登録
- Package化に必要なモジュールのインストール
- Packageソースの作成
- init.pyの作成
- メインソースの作成
- MANIFEST.inの作成
- setup.pyの作成
- README.mdの作成 1 LICENSEの作成
- Twineを使ってPyPIに登録
事前準備
基本的に、パッケージ化に必要なsetuptoolsとwheel はinstall済みなことが多いですが、upgradeを行います。また後述しますがPyPIのupload用にtwineというモジュールを使うので、こちらもインストールしておきます。（モジュールの実行環境とは別にPyPIへのupload用にpyenvなどで環境を切り分けてから実行したほうが良いかと思います。）
python3 -m pip install --upgrade setuptools wheel twine
Packageソースの作成
本題のPyPIの登録についてです。PyPIの登録は今回初めて行いました。ドキュメントはあるものの、ちょっとよくわからないというのが正直なところでした。なのでいろんなサイトを参考にしてやってみました。 基本いくつかのステップに分けられるのでステップに分けて説明します。
# QEPPIの例（本物とちょっと違うけど） ├── setup.py ├── MANIFEST.in ├── QEPPI ← ここをモジュール名と合わせておくと吉 │ ├── __init__.py │ ├── QEPPI.py │ ├── constant.py │ ├── util.py │ └── version.py ├── README.md ├── LICENSE
- setup.py : パッケージ作成情報を記述する。（詳細は後述）
- MANIFEST.in : パッケージに追加、または除外するファイルを記述する。 例えばrequirements.txtなど。 LICENSE, README.md setup.pyなどは指定せずとも勝手にパッケージングされます。取り除きたい場合はexcludeであえて含ませないといったことが出来ます。また、setup.pyの仕様でrequirements.txtを使う場合はMANIFEST.in に書かないと怒られますので必ず書きましょう。
# MANIFEST.in
include *.md
exclude README.md
include requirements.txt
- init.py : パッケージ基本情報を記述。 例えば以下のような感じ。 一番上のimportが結構重要です。
# __init__.py from .<ファイル> import * ← この行ポイント __copyright__ = "Copyright (C) 2021 balcktanktop" __version__ = "0.1.10" __license__ = "MIT" __author__ = "くろたんく" __author_email__ = "くろたんく@gmail.com" __url__ = "http://github.com/blacktanktop/repository"
- setup.py
一番肝心のsetup.pyです。まず例です。
from setuptools import setup exec(open("QEPPI/version.py").read()) with open("README.md", "r", encoding="utf-8") as fh: long_description = fh.read() setup( name="QEPPI", version=__version__, author="blacktanktop, author_email="くろたんく@gmail.com", description="Calculation module of QEPPI", long_description=long_description, long_description_content_type="text/markdown", url="https://github.com/ohuelab/QEPPI/", license="MIT", packages=["QEPPI"], install_requires=[ "rdkit-pypi>=2021.3.1.5", "numpy>=1.19.5", "pandas>=1.1.5", ], classifiers=[ "Programming Language :: Python :: 3.7", "Programming Language :: Python :: 3.8", "License :: OSI Approved :: MIT License", "Operating System :: OS Independent", "Topic :: Scientific/Engineering :: Chemistry", "Topic :: Scientific/Engineering :: Bio-Informatics", ], )
name : パッケージ名称
version : バージョン
author : 著作者名
author_email : 著作者のメールアドレス
description : 簡単な説明
long_description : 詳細の説明 後述しますがREADME.mdファイルの内容をそのまま書き込むこともできます。
url : パッケージのWeb page GitHubのリポジトリURLなど
license : パッケージのライセンス（MITなど）
packages : モジュールリスト (Mainソースのディレクトリ名を指定する)
install_requires : Dependencyのあるパッケージ
classifiers : 分類語のリスト 実際にPyPIで分類リストがあるのでそれを指定する。
冒頭の2行は
exec(open("QEPPI/version.py").read())- とするとverion.pyに書いてあるversion=0.1.10を読み込めるので、バージョンを変数で管理するためです。
with open("README.md", "r", encoding="utf-8") as fh:
long_description = fh.read()
- long_descriptionという変数にREADME.mdのテキストを突っ込むことで、 PyPIに登録したときの画面をREADME.mdと同じにするための方法です。
また、install_requiresをrequirements.txtで指定したい場合は、
def _requires_from_file(filename): return open(filename).read().splitlines()
のような関数を作っておいて
install_requires=_requires_from_file("requirements.txt")
などとします。
ただ、最近ではsetup.pyはシンプルにして、setup.cfgというconfigファイルに全部設定を書くというのが主流だそうです。 参考までに例を上げておきます。（マダよくわかってないがiniファイルっぽい作りのものでsetup()の括弧内のものを別のまとめ方でもできるよということです。）
[metadata]
name = package_name
version = attr: src.VERSION
description = short package description
long_description = file: README.md
keywords = foo, bar
license = MIT License
classifiers =
Programming Language :: Python :: 3.7
[options]
zip_safe = False
include_package_data = True
packages = find:
scripts =
bin/first.py
bin/second.py
install_requires =
pandas
numpy; python_version == "3.7"
[options.package_data]
* = *.md
さて、これで下準備ができました！あとはビルドしてPyPIにupするだけです。
ちょっとテスト
ここまで出来ていると、以下のコマンドでinstallテストが可能です。
python setup.py install
pip listすればinstallが確認出来ると思います。
また、versionやその他の定義変数を設定している場合は以下のような確認もできます。
>>> import QEPPI >>> QEPPI.__version__ '0.1.10'
ビルドの準備
ビルドするには、setuptoolsでビルドします。 setup.pyがある階層で以下のコマンドを叩くと完了です。
python setup.py sdist bdist_wheel
├── setup.py ├── MANIFEST.in ├── Makefile ├── QEPPI │ ├── QEPPI.py │ ├── __init__.py │ ├── constant.py │ ├── util.py │ └── version.py ├── QEPPI.egg-info │ ├── PKG-INFO │ ├── SOURCES.txt │ ├── dependency_links.txt │ ├── requires.txt │ └── top_level.txt ├── build │ ├── bdist.macosx-10.12-x86_64 │ └── lib │ └── QEPPI │ ├── QEPPI.py │ ├── __init__.py │ ├── constant.py │ ├── util.py │ └── version.py ├── dist │ ├── QEPPI-0.1.10-py3-none-any.whl │ └── QEPPI-0.1.10.tar.gz ├── README.md ├── LICENSE
最初のディレクトリと比べると、.egg-infoとbuild/とdist/ が作られます。最終的に登録するのはdistの中身になります。
PyPIへのupload
早速登録したいのですが、まずいわゆるユーザー登録の必要があります。そして、PyPIにはテスト用の環境と、本番用の環境があります。
また、setup.pyのコマンドでupしてもいいのですが、今回はtwineを使います。（最初にインストールした） github.com
また、README.mdをそのままlong descriptionに設定している場合は、本当に今のREADME.mdで良いかをしっかりと検討して、やりきってからupに進んだほうが良いです。というのもTest.PyPIもPyPIもupのやり直しができません。versionを同じままで、descriptionだけ変えたいということができない（と思う）ので気をつけましょう。基本的に変更はversionを少しでもいいから上げる（1.0.0なら1.0.1とか） 削除しても同じ名前だと記録が残っているので、削除してもダメです。
Test.PyPI (練習用)へのupload
README.mdのチェックが終わったら、upします。 以下のコマンドでTest.PyPIにup出来ます
twine upload --repository-url https://test.pypi.org/legacy/ dist/*
パスが求められるのでユーザー登録したときのusernameとpassを入れましょう。
upが終わったら、出力されるURLを見に行きましょう
こんな感じなので、
pip install -i https://test.pypi.org/simple/ QEPPI
のようにコマンドを叩くと、ローカル環境にインストールされます。 インストール後に、適宜問題が無いかチェックします。必要があれば、テストコードを走らせる等しましょう。
PyPI (本番)へのupload
ここまで来てしまえば、同じ様に本番にupします。
twine upload --repository-url https://pypi.org/legacy/ dist/*
こちらでも、パスが求められるのでユーザー登録したときのusernameとpassを入れましょう。
upが終わったら、出力されるURLを見に行きましょう。
こんな感じになって、PyPI登録出来ました!!!
あとは、適当な環境で
pip install QEPPI
のようにインストールをすると、依存関係もインストールされるのが確認できます。
Makefileによるタスクフロー化
これからバージョンを上げていくときに便利なようにMakefileを使って、タスク化してしまいましょう。
その前に、毎回、パスを入れるのも面倒なのとセキュリティ的にもちょっと微妙なので、API tokenを使って登録出来るようにします。アカウント設定の下の方から取得出来るのでそれぞれ取得して下さい。
そうしたら、~/.pypircを作って下さい。中身は以下のようにしましょう。usernameをtokenとするとpassはAPI tokenと認識するようです。（ちなみにここに、自分のusernameとpassを書いてもよいがtokenのほうが良いですね）
[distutils] index-servers = pypi testpypi [pypi] username = __token__ password = pypi-~~~tokenを入れる [testpypi] username = __token__ password = pypi-~~~tokenを入れる
これで設定はバッチリです。
では、話を戻して、Makefikeの例を見ていきましょう。
私はコマンドを手で叩くのが一周したら、必ずこの様なMakefileを書きます。Rakeでも良いですが環境を作る必要がないのでMakefileをタスク実行ツールととして使っています。
make clean : 一度、Buildするとegg.Infoとかdistの前のバージョンが残ったままになってしまいます。なので、まずcleanで過去のパッケージを消します。単純にrm -rfで消します。
make build : ビルドしてupするためのdistを作ります。
make test-deploy : Test.PyPIにupします。
make deploy : PyPIにupします。
この様にMakefileでタスク化しておくとしばらく経ってからのバージョン変更の際にも、記憶に優しく実行できますね。
あとはパッケージをUpdateしていきましょう!
ポイント
PyPIのdescriptionとGitHubのREADME.mdが一致しないとなんか気持ち悪いですが、PyPIは過去のバージョン、GitHubがdevelopバージョンと割り切って、GitHubで開発を進めて、ある程度機能が備わったらPyPIにバージョンを上げたものをuploadといった様にするのが良いかと思います。
今回の内容をまとめたスライド
研究概要 + PyPI登録に関連する資料を作成しました。 Speaker Deckにupしてありますので興味ある方はそちらも御覧ください。
終わりに
今回は、自分が開発したパッケージをpip install QEPPIのようにインストール出来るようにするために、PyPIにuploadする手順をまとめました。初めて行った作業で、まだわかっていない部分もありますが、だいたいこの手順で行えばそこまで問題は起きないかなと思います。
今回改めて、普段何気なく使っているOSSツールがとても大変な労力をかけてやられているのだと実感しました。
また、質問を受けて思ったのは、 * Condaでの公開方法との違い * PyPIへuploadするときのテスト関係 * プラットフォーム別のバイナリーデータについて ここらへんは、今後、きちんと調べてきたいと思います。
資料作って、話し、質問を受けるということをするととても勉強になり、参加してよかったなと思いました。
参考にしたブログ等
公式以外で参考にしたものは以下です。ありがとうございました。
参考文献
導入でPPIの説明に出てきた内容の文献はこちらです。
Shin, W.-H.; Kumazawa, K.; Imai, K.; Hirokawa, T.; Kihara, D. Current challenges and opportunities in designing protein–protein interaction targeted drugs. Adv. Appl. Bioinform. Chem. 2020, 13, 11–25, doi:10.2147/AABC.S235542.
Morelli, X.; Bourgeas, R.; Roche, P. Chemical and structural lessons from recent successes in protein-protein interaction inhibition (2P2I). Curr. Opin. Chem. Biol. 2011, 15, 475–481, doi:10.1016/j.cbpa.2011.05.024.
Bickerton, G.R.; Paolini, G. V.; Besnard, J.; Muresan, S.; Hopkins, A.L. Quantifying the chemical beauty of drugs. Nat. Chem. 2012, 4, 90–98, doi:10.1038/nchem.1243.
Jumper, J.; Evans, R.; Pritzel, A.; Green, T.; Figurnov, M.; Ronneberger, O.; Tunyasuvunakool, K.; Bates, R.; Žídek, A.; Potapenko, A.; et al. Highly accurate protein structure prediction with AlphaFold. Nature 2021, doi:10.1038/s41586-021-03819-2.
QEPPI論文がPublishされました。
はじめに
2021/10/10に自身がこれまで取り組んできた研究成果をまとめた論文がInternational Journal of Molecular Sciences誌に掲載されました。
Kosugi T, Ohue M. Quantitative Estimate Index for Early-Stage Screening of Compounds Targeting Protein-Protein Interactions. International Journal of Molecular Sciences. 2021; 22(20):10925. https://doi.org/10.3390/ijms222010925
論文概要
タンパク質間相互作用（PPI）は最近注目されている創薬の標的です。薬となる化合物を設計する際に、その化合物がPPIを標的にできそうかどうかの度合いを定量的にスコア化する手法はありませんでした。そこで、化合物がPPIを標的にできそうかどうかを定量的にスコア化する手法を開発したという内容になっています。
簡単に論文をまとめたスライド
@antiplasticsさんからBio"Pack"athon2021 #10へ参加しませんか？ということで誘っていただいたので研究概要 + PyPI登録に関連する資料を作成しました。Speaker Deckにupしてありますので興味ある方はそちらも御覧ください。
QEPPIのコード
論文で用いられている、低分子化合物のPPIを標的にできそう度合いをスコア化した「QEPPI」はGitHubで公開しています。 https://github.com/ohuelab/QEPPI
QEPPIのロゴ
今回はQEPPIをイメージしやすいように、ロゴを作成しました。
Graphvizを用いたニューラルネットのGraph構造の作図
ニューラルネットのGraphをサクッと作りたく、Graphvizで簡単にできたのでその紹介。
細かい設定を色々試したかったので、その結果をGistにupしてお来ました。
かなり細かい設定ができるので、コードからどこをいじると何が変化するかっていうのを理解しながら適宜調整すると良いかと思います。
ポイントは、
* バックグラウンドを透明にする bgcolor="transparent"
* ノード群が四角で囲われるのでその線を透明にするsubgraph cluster内での、color="transparent";
この2つをやっておけばpngで背景透明でいい感じに出力できます。（逆にそれぞれ色を設定してやってみると、どういうことかわかります）
でこのコードをColabでも自身の環境でもいいので叩くと、
こんな感じのものが出来上がります。（実際に出来上がるのはもっと高画質です。）
