「dependency」を含む日記 RSS

はてなキーワード: dependencyとは

2017-11-29

ニコニコ動画(く)リリース失敗に寄せて

そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います

Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita

ドワンゴアカウントシステムScalaコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています

ドワンゴユーザーアカウント基盤は明らかに破綻しています10 年以上にわたりガラケー時代から今に至るまで多くの業務コードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います

ニコニコ生放送におけるdockerの活用事例:dwango エンジニア ブロマガ:ドワンゴ研究開発チャンネル(ドワンゴエンジニア) - ニコニコチャンネル:生活

ニコニコ生放送(以下「生放送」)ではバックエンドフロントエンドサーバーを建てる環境として、2016年からDocker Swarm採用し始めています

Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができますさらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上ゼロコンフィグレーション)で実装たことは素晴らしいと思いますしかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。

私は kubernetes が嫌いです。 Google 製品開発者UX考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます

http://gihyo.jp/dev/serial/01/dwango-engineersoul/0002 大量トラフィックを支えるインフラ独自プロトコル,ファイルシステム実装もいとわない!~

実は分散ファイルシステム独自に開発しました。もともと既存オープンソースファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自調査開発を進めることにしました。

現状は初期バージョンの開発完了にかなり近づいています

こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって

  1. OSS分散ファイルシステム使用するという目論見が失敗した
  2. 自前の分散ファイルシステムは 9 カ月まえの時点で全く完成していない

ということが分かります

なぜ彼らはパブリッククラウドCDN を使わないのか?

触れない話: 事実上全然稼働しなかった CTO北の将軍様

パブリッククラウド特に CDN採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザー結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定理由をここでは探ってみます

ASCII.jp:niconico(く)開発の遅れを謝罪

動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています

ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しか現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。

CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性

大規模配信 | 強烈な価格競争 原価割れ総合サービス提供で収支合わせ)

要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴCDN流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います

ただしこの点において今後もビジネス環境技術環境現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。

まとめ

まあもう無理でしょいろいろ

2016-12-07

http://anond.hatelabo.jp/20161207020046

依存地獄( Dependency Hell )かな。https://en.wikipedia.org/wiki/Dependency_hell

An application depends on many libraries, requiring lengthy downloads, large amounts of disk space, ...

(アプリケーションがたくさんのライブラリ依存していて、長時間ダウンロードや大量のディスク容量が必要で、...)

app depends on liba, which depends on libb, ..., which depends on libz. This is distinct from "many dependencies" if the dependencies must be resolved manually (e.g., on attempting to install app, the user is prompted to install liba first. On attempting to install liba, the user is then prompted to install libb.).

(アプリケーションがAを必要としていて、そのAはBを必要としていて、(中略)Zを必要としているような場合ユーザーが手動で依存性を解決しなければいけない場合には、先ほどの例とは違い、ユーザーは「アプリケーションインストールしようとしたらAが必要と言われ、AをインストールしようとしたらBが必要と言われる」目に遭うことになる)

2016-07-25

gitにおけるコミットログ/メッセージ例文集100

私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくま単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。

要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのであるググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか

仕方なく自分でまとめたので、増田に垂れ流しておく。

はじめに

ここで挙げているコミットログは全て実際のコミットログから転載である。当然ながら各コミットログ著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユース範囲なら許してくれるだろうと考え名前プロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。

抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリGitHubSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した(あわせて前処理として、コミットログ冒頭のタグ情報は消去した)。

結果として対象としたリポジトリは以下の通り。

atomのみ5400件抽出していたため、計25400件のコミットログベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。

こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である個人的に「うーんこの」と思った表現も、散見される場合は載せた。

ということで、以下用例を羅列していく。

用例集

オプションフラグメニューを追加した
ファイルを追加した
メソッド機能を追加した
実装を別のものへ切り替えた
  • Use args.resourcePath instead of args.devResourcePath
  • Use arrays instead of while loops
  • Use auto instead of repeating explicit class names
  • Use weak pointer instead of manual bookkeeping
  • Change all uses of 'CInt' to 'Int32' in the SDK overlay
  • Change Integer#year to return a Fixnum instead of a Float to improve consistency
新しく何かに対応した/機能上の制約を取り払った
何かを使うようにした
より好ましい実装に改良した
何かを出来ない/しないようにした
  • Don't bail reading a metadata instance if swift_isaMask isn't available
  • Don't exit until the parent asks for an instance
  • Don't include Parent pointer in Nominal/BoundGeneric TypeRef uniquing
  • Don't use MatchesExtension for matching filters
  • Don't use ES6 class for AutoUpdater windows class
  • Don't use MatchesExtension for matching filters
  • Avoid `distinct` if a subquery has already materialized
  • Avoid infinite recursion when bad values are passed to tz aware fields
オブジェクトの内容や挙動確認やすくした
Assertを追加した
不要コードを除去した
コードを移動した
名前修正した
さなバグタイポ修正した, 警告を潰した
バグや好ましくない挙動修正した
テストコメントドキュメントを追加した
テストを削除した
テストコメント修正した
ドキュメント修正した

表現傾向とまとめ

以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。

Add1149
Fix1014
Update584
Remove566
Use382
Don't260
Make228
Move178
Change103
Rename85
Improve76
Avoid68
Allow65
Implement60
Handle58

コミットログの基本形はもちろん動詞 + 名詞である名詞固有名詞複数形、不可算名詞が多いが、単数形場合冠詞は a が使われるか、あるいは省略される。the はまず使われない。

何かを追加した、という表現では非常に広く Add が使われる。メソッドからテストドキュメントに至るまで大概これでまかなえる。

一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typocrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である

Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合Make sure が使われる(こちらはthat節が取れる)。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う(Ensure はさらに重い表現っぽい)。

また、Fixtypo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメントコメントテストに使われ、本体コード修正に対しては使われない。本体コード修正にあわせてテスト更新したなら Update が使われる。ただ、テスト機構それ自体バグ修正したなら Fix である

無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)からのもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合Don't use を使うことが多い。

何かをしないようにしたなら Don't を、内部実装効率化なら Make A + 比較級/形容詞Improve が使われる。

中身の変更を伴わない単なる名前の変更なら Rename A to B、コード機能論理上の場所を移動させたなら Move A to B である

この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。

余談

コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である

一方で、シンプル単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。

おわりに

8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体効率のいい学習になるという話と同じだと思う。

このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。

2014-10-11

アプリ屋がRailsを初めて触ってみて感じた事

Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。

発想が古臭い

モバイルファーストAPIファースト文脈ハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLゴリゴリ生成するなんてよほど特殊最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLメタプログラミング等のテクニカル技法宝石のように鏤められている様はまるでエジプト時代骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。

モデルMVC

Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsクラスディレクトリという特定実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナル概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。

レールから外れる辛さ

Rails界隈の人がよく「Rails流儀」や「正しい"MVC"」というのを口角泡を飛ばし議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRails世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインサービスレイヤ名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別名前役割を与えられても正直しんどいので、皆が皆libゴミを放り込んでいく様子にも納得がいきました。

レイヤ?何それおいしいの

RailsAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsリファクタ手法と称されているものクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときセットポジションDDD青本を投げつける必要が有るなと思いました。

TDDやれんのか

ビューとコントローラを結合させた場合結合テストはCapybaraとかのBDDマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。

分業とか出来るんだろうか

ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーRubyバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。

RESTとかきついです

RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思いますGETbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTあくまリソース抽象化する美しい概念なので、アクション副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間しか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計拝借することはよしとしても、「○○はRESTでは無い故云々~」みたいな注文はやめて頂きたいものです。

そんなに嫌なら他に行けば

とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまサーバーサイド初心者感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います

だってRuby楽しいんだもの

2008-04-05

さくらの旧(?)専用サーバ CentOS 4.6 を Linux-Vserver に入れ替えてみた

前置き

契約直後の初期状態

  • ホスト名をsakura2とした。
  • sshd と vsftpd が動いていた。
[admin@sakura2 ~]$ uname -a
Linux sakura2 2.6.9-67.0.4.ELsmp #1 SMP Sun Feb 3 07:08:57 EST 2008 i686 athlon i386 GNU/Linux
[admin@sakura2 ~]$ cat /etc/issue.net
CentOS release 4.6 (Final)
Kernel \r on an \m

CentOS 5 へのアップグレード(?)

中身の整理
  • なるべく最小構成に近い最新のCentOS4.6にしてみる。
# yum update
# yum remove emacs emacspeak emacs-leim emacs-common
# yum remove NetworkManager
# yum remove bluez-bluefw bluez-hcidump bluez-libs bluez-utils
# yum remove cups cups-libs
# yum remove irda-utils isdn4k-utils pcmcia-cs wireless-tools
# yum remove wpa_supplicant gpm xinetd
# yum remove ppp nfs-utils lksctp-tools autofs
# yum remove xorg-x11-libs
# yum remove selinux-policy-targeted
# yum remove vsftpd
# yum clean all
CentOS 5 にアップグレード(?)してみる
[admin@sakura2 ~]$ uname -a
Linux sakura2 2.6.9-67.0.7.ELsmp #1 SMP Sat Mar 15 06:54:55 EDT 2008 i686 athlon i386 GNU/Linux
# rpm -Uvh http://mirror.centos.org/centos/5/os/i386/CentOS/centos-release-notes-5.1.0-2.i386.rpm \
http://mirror.centos.org/centos/5/os/i386/CentOS/centos-release-5-1.0.el5.centos.1.i386.rpm
[root@sakura2 admin]# cat /etc/issue.net
CentOS release 5 (Final)
Kernel \r on an \m

# yum update glib procps udev iptables
# rpm -Uvh --nodeps http://mirror.centos.org/centos/5/os/i386/CentOS/initscripts-8.45.17.EL-1.el5.centos.1.i386.rpm \
http://mirror.centos.org/centos/5/os/i386/CentOS/mkinitrd-5.1.19.6-19.i386.rpm
# rpm -Uvh http://mirror.centos.org/centos/5/os/i386/CentOS/e2fsprogs-1.39-10.el5.i386.rpm \
http://mirror.centos.org/centos/5/os/i386/CentOS/e2fsprogs-libs-1.39-10.el5.i386.rpm \
http://mirror.centos.org/centos/5/os/i386/CentOS/e2fsprogs-devel-1.39-10.el5.i386.rpm
# rpm -Uvh http://mirror.centos.org/centos/5/os/i386/CentOS/kernel-2.6.18-53.el5.i686.rpm
[admin@sakura2 ~]$ uname -a
Linux sakura2 2.6.18-53.el5 #1 SMP Mon Nov 12 02:22:48 EST 2007 i686 athlon i386 GNU/Linux

# yum clean all

[root@sakura2 admin]# yum --version
Loading "fastestmirror" plugin
2.4.3
[root@sakura2 admin]# rpm --version
RPM version 4.3.3
# yum update
Error: Missing Dependency: python-abi = 2.3 is needed by package python-elementtree
  • 解決法がわからないので放置

Linux-Vserver の導入

# vi /etc/ssh/sshd_config
# /etc/init.d/sshd restart
# vi /etc/yum.repos.d/dhozac-vserver.repo
# yum update kernel
# yum install util-vserver{,-core,-lib,-sysv,-build}
[admin@sakura2 ~]$ uname -a
Linux sakura2 2.6.22.19-vs2.3.0.34.1 #1 SMP Mon Mar 17 05:32:04 EDT 2008 i686 athlon i386 GNU/Linux

ホストOS環境の整備

# yum update bash screen rsync
# /etc/init.d/iptables save
# /etc/init.d/iptables start
# cat /etc/sysconfig/iptables

# Generated by iptables-save v1.3.5 on Mon Mar 24 19:57:07 2008
**filter
:INPUT ACCEPT [1067:96557]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [63680:6208436]
:e0 - [0:0]
-A INPUT -i eth0 -j e0
-A e0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A e0 -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A e0 -p tcp -m tcp --dport 22 -j ACCEPT
-A e0 -p tcp -m tcp --dport 80 -j ACCEPT
-A e0 -p tcp -m tcp --dport 443 -j ACCEPT
-A e0 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Mon Mar 24 19:57:07 2008
# Generated by iptables-save v1.3.5 on Mon Mar 24 19:57:07 2008
**nat
:PREROUTING ACCEPT [179:10642]
:POSTROUTING ACCEPT [213:13895]
:OUTPUT ACCEPT [251:16220]
-A PREROUTING -s ! 10.0.0.0/255.255.255.0 -p tcp -m tcp --dport NNNN -j DNAT --to-destination 10.0.0.1:22
-A POSTROUTING -s 10.0.0.0/255.255.255.0 -d ! 10.0.0.0/255.255.255.0 -j SNAT --to-source AAA.BBB.CCC.DDD
COMMIT
# Completed on Mon Mar 24 19:57:07 2008

ゲストOSの設定

[root@sakura2 ~]# /usr/sbin/vserver-stat
CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
40013   27 301.5M  73.8M  30m36s31  56m38s90  11d06h56 one
40015    5  10.8M   4.4M   0m28s33   0m12s68   9d04h23 two
40016    2   4.2M   1.3M   0m00s47   0m00s64   0m01s97 three

追記

2008-03-21

[]Python 2.5のdistutilsで、Visual Studio 2005を使いたい!

目的

Visual Studio 2005しかインストールしてない場合、Python 2.5だとdistutilsが正しく動かないっぽいので、どうにかしたいYO!

なんでVisual Studio 2005だと、distutilsが動かないんかな?

distutilsでVisual Studioを使うときのコンパイル環境は、sysモジュールのversionプロパティを参照して環境を選択をしているようです。Pythonインタプリタを起動して、以下のような命令を実行してみると、sys.versionプロパティが確認できます。

import sys;print sys.version

Python 2.5.2だと、以下のようになっています。Visual Studio 2003の環境が使われるようです。

2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]

Python 2.6a1だと、以下のようになっています。Visual Studio 2008の環境が使われるようです。

2.6a1 (r26a1:61155, Mar  1 2008, 12:11:56) [MSC v.1500 32 bit (Intel)]

以上から察するに、Python 2.5.2とPython 2.6のどちらでも、Visual Studio 2005の環境が選択されることはないっぽいです。うーん、困った!

解決策

Python 2.6とVisual Studio 2008をインストールしよう!」というのを真っ先に思いつきましたが、あんまり環境を変えたくないんだよなー。というわけで、環境の変更を最低限に抑えてどうにかしてみました。簡単に言うと、distutilsだけの置き換えをしました。

Python 2.6 をインストールする

Python 2.6の公式ダウンロードページから、Windows版のインストーラーをダウンロードして、適当な場所にインストールしてください。

distutilsだけ置き換える

"Python-2.5.2/Lib/distutils"を別の場所に移動し、"Python-2.6a1/Lib/distutils"を"Python-2.5.2/Lib"以下にコピーしてください。以降はPython 2.6は必要ないので、アンインストールして構いません。

ファイルの修正
  • 例外をPython 2.5.2で許されている形式に変更。
  • get_build_version()関数で強制的に8を返すように変更。

上記の2点の変更を行います。distutilsディレクトリに、以下のパッチをあててください。

Index: msvccompiler.py
===================================================================
--- msvccompiler.py
+++ msvccompiler.py
@@ -170,6 +170,7 @@
     if majorVersion == 6:
         minorVersion = 0
     if majorVersion >= 6:
+        return 8
         return majorVersion + minorVersion
     # else we don't know what version of the compiler this is
     return None
Index: msvc9compiler.py
===================================================================
--- msvc9compiler.py
+++ msvc9compiler.py
@@ -128,7 +128,7 @@
                                "sdkinstallrootv2.0")
             else:
                 raise KeyError("sdkinstallrootv2.0")
-        except KeyError as exc: #
+        except KeyError, exc: #
             raise DistutilsPlatformError(
             """Python was built with Visual Studio 2008;
 extensions must be built with a compiler than can generate compatible binaries.
@@ -172,6 +172,7 @@
     if majorVersion == 6:
         minorVersion = 0
     if majorVersion >= 6:
+        return 8
         return majorVersion + minorVersion
     # else we don't know what version of the compiler this is
     return None
@@ -455,7 +456,7 @@
                 try:
                     self.spawn([self.rc] + pp_opts +
                                [output_opt] + [input_opt])
-                except DistutilsExecError as msg:
+                except DistutilsExecError, msg:
                     raise CompileError(msg)
                 continue
             elif ext in self._mc_extensions:
@@ -482,7 +483,7 @@
                     self.spawn([self.rc] +
                                ["/fo" + obj] + [rc_file])
 
-                except DistutilsExecError as msg:
+                except DistutilsExecError, msg:
                     raise CompileError(msg)
                 continue
             else:
@@ -495,7 +496,7 @@
                 self.spawn([self.cc] + compile_opts + pp_opts +
                            [input_opt, output_opt] +
                            extra_postargs)
-            except DistutilsExecError as msg:
+            except DistutilsExecError, msg:
                 raise CompileError(msg)
 
         return objects
@@ -520,7 +521,7 @@
                 pass # XXX what goes here?
             try:
                 self.spawn([self.lib] + lib_args)
-            except DistutilsExecError as msg:
+            except DistutilsExecError, msg:
                 raise LibError(msg)
         else:
             log.debug("skipping %s (up-to-date)", output_filename)
@@ -598,7 +599,7 @@
             self.mkpath(os.path.dirname(output_filename))
             try:
                 self.spawn([self.linker] + ld_args)
-            except DistutilsExecError as msg:
+            except DistutilsExecError, msg:
                 raise LinkError(msg)
 
         else:
manifestファイルを作る

python.exeと同じディレクトリに、以下のXMLを"python.exe.manifest"として保存してください。

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type='win32'
        name='Microsoft.VC80.CRT'
        version='8.0.50608.0'
        processorArchitecture='x86'
        publicKeyToken='1fc8b3b9a1e18e3b'
        />
    </dependentAssembly>
  </dependency>
</assembly>

これで終わりです。

2008-03-15

[][]PythonからSWIG経由でVisual Studio 2005を使って困ったこと

以上のような組み合わせで出くわした困ったことと、その解決策をメモしておきます。

setup.py を実行するとエラーが表示された!

Python was built with Visual Studio 2003;

extensions must be built with a compiler than can generate compatible binaries.

Visual Studio 2003 was not found on this system. If you have Cygwin installed,

you can try compiling with MingW32, by passing "-c mingw32" to setup.py.

setup.pyに.iファイルとか.cppファイルを記述して実行すると、こんな感じのエラーメッセージが表示されました。うーん、困った!

http://labs.cybozu.co.jp/blog/mitsunari/2007/08/vc2005boostpython.html

上記のページを参考にして、"%Pythonインストールしたフォルダ%/Lib/distutils/msvcompiler.py"を以下のように修正してみたら解決できました。ありがとうありがとう

--- msvccompiler.py    2007-04-04 17:17:12.000000000 +0900
+++ 
@@ -126,7 +126,7 @@
         self.set_macro("FrameworkDir", net, "installroot")
         try:
             if version > 7.0:
-                self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv1.1")
+                self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv2.0")
             else:
                 self.set_macro("FrameworkSDKDir", net, "sdkinstallroot")
         except KeyError, exc: #
@@ -252,7 +252,10 @@

     def initialize(self):
         self.__paths = []
-        if os.environ.has_key("DISTUTILS_USE_SDK") and os.environ.has_key("MSSdk") and self.find_exe("cl.exe"):
+        if self.__version >= 7.1 or (
+            os.environ.has_key("DISTUTILS_USE_SDK") and
+            os.environ.has_key("MSSdk") and
+            self.find_exe("cl.exe")):
             # Assume that the SDK set up everything alright; don't try to be
             # smarter
             self.cc = "cl.exe"
@@ -288,10 +291,16 @@

         self.preprocess_options = None
         if self.__arch == "Intel":
-            self.compile_options = [ '/nologo', '/Ox', '/MD', '/W3', '/GX' ,
-                                     '/DNDEBUG']
-            self.compile_options_debug = ['/nologo', '/Od', '/MDd', '/W3', '/GX',
-                                          '/Z7', '/D_DEBUG']
+            if self.__version >= 7.1:
+                self.compile_options = [
+                    '/nologo', '/Ox', '/MD',  '/W3', '/EHsc', '/DNDEBUG']
+                self.compile_options_debug = [
+                    '/nologo', '/Od', '/MDd', '/W3', '/EHsc', '/Z7', '/D_DEBUG']
+            else:
+                self.compile_options = [
+                    '/nologo', '/Ox', '/MD',  '/W3', '/GX',  '/DNDEBUG']
+                self.compile_options_debug = [
+                    '/nologo', '/Od', '/MDd', '/W3', '/GX', '/Z7', '/D_DEBUG']
         else:
             # Win64

cl.exeが見つからないと言われた!

setup.pyを実行するとcl.exeが見つからないみたいなエラーが表示されました。これは、アレだ。「パス通せ!」ということですね。bashを起動するときのバッチファイル(たぶん"cygwin.bat"とか)で、以下のような行を入れてやれば解決しました。

call "%VS80COMNTOOLS%vsvars32.bat"

setup.pyを実行したときに"basetsd.h"が開けないと言われた!

d:\python25\include\pyconfig.h(189) : fatal error C1083: include ファイルを開けません。'basetsd.h': No such file or directory

error: command 'cl.exe' failed with exit status 2

setup.pyを実行すると、上のようなエラーが表示されました。

http://d.hatena.ne.jp/ousttrue/20070531/1180556273

上記のサイトを見るとインクルードパスが通っていない場所に"basetsd.h"があるのが原因なので、"cygwin.bat"にインクルードパスの設定をしておきました。

call "%VS80COMNTOOLS%vsvars32.bat"
set INCLUDE=C:\Program Files\Microsoft Platform SDK\Include;%INCLUDE%

setup.pyを実行したときのリンク時にエラーが発生した!

link: extra operand `/INCREMENTAL:NO'

詳しくは `link --help' を実行して下さい.

error: command 'link.exe' failed with exit status 1

これは、cygwinのほうのlink.exeが実行されてるのが原因でした。スマートな解決策ではありませんが、cygwinのほうのlink.exeをリネームして解決。パスの設定順序とかでどうにかできるといいんだけど、どうすればいいんかな。

MSVCR80.dllが見つからないと言われた!

MSVCR80.dllが見つからなかったため、このアプリケーションを開始できませんでした。アプリケーションインストールし直すとこの問題は解決される場合があります。

SWIGが生成した.pyファイルをimportしたら、こんな感じのエラーダイアログが表示されたよ。うーん、困った!

http://d.hatena.ne.jp/moriyoshi/20070525

上記のページを参考にして、"%Pythonインストールしたフォルダ%/python.exe.manifest"として以下のようなファイルを新しく作ったら、解決できました。ありがとうありがとう

あとこれ、bashから実行したらエラーダイアログが表示されず、importするモジュールが見つからないみたいなエラーメッセージが出力されるだけだったよ。

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>
</assembly>
 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん