Getting Started - PyPI Docs
Welcome to PyPI User Documentation Organization Accounts Trusted Publishers Publishing to PyPI with a Trusted Publisher "Trusted publishing" is our term for using the OpenID Connect (OIDC) standard to exchange short-lived identity tokens between a trusted third-party service and PyPI. This method can be used in automated environments and eliminates the need to use manually generated API tokens to
AWS認証情報が盗まれる2つのライブラリ改ざんについてまとめてみた - piyolog
2022年5月24日（米国時間）、SANS ISCのフォーラムでPython向けライブラリの1つ（その後PHP向けライブラリでも判明）が第三者により不正なコードを含むアップデートが行われていたとして注意を呼び掛ける投稿が行われました。その後この行為に関わっていたとして実行者とみられる人物が顛末を公開しました。ここでは関連する情報をまとめます。 改ざんされた2つのライブラリ 今回影響が確認されたのPython Package Index（Pypi.org）で公開されている「ctx」、Packagist（Packagist.org）で公開されている「PHPass」の2つ。 影響を受けたライブラリ インストール実績 改ざんされたとみられる期間 概要 ctx 約75万回 2022年5月14日～5月24日頃 辞書(dict型オブジェクト)を操作するユーティリティを提供するPython向けのパッケージ
PythonパッケージをPyPIにアップロードする際にMarkdownをreSTに変換 - Steel Dragon 14106
PythonパッケージをPyPIにアップロードする際にMarkdownをreSTに変換 By raimon, 2018-01-30(火), in category Python MarkdownフォーマットではHTML描画されない問題 Pythonパッケージの開発もGitHubが使われるケースが増えている。それに伴って、パッケージのドキュメントもMarkdownフォーマットが採用されるケースも散見される。 ただし、MarkdownフォーマットでPyPIサーバーにアップロードすると、Web UIではHTML描画されないため、ユーザーフレンドリーではない。 そこで、Pythonパッケージの新しいバージョンをPyPIサーバーにアップロードする際に、オンデマンドでreStructuredText（以降「reST」）フォーマットにオンデマンドで変換してやると、いい感じにWeb UIでもHTML描画さ
PyPIデビュー2015
Use the left and right arrow keys or click the left and right edges of the page to navigate between slides. (Press 'H' or navigate to hide this message.)
GitHub - pypa/sampleproject: A sample project that exists for PyPUG's "Tutorial on Packaging and Distributing Projects"
A sample project that exists as an aid to the Python Packaging User Guide's Tutorial on Packaging and Distributing Projects. This project does not aim to cover best practices for Python project development as a whole. For example, it does not provide guidance or tool recommendations for version control, documentation, or testing. The source for this project is available here. The metadata for a Py
たった一ファイルの python スクリプトから始めるOSS開発入門 / PyCon JP 2016
PyCon JP 2016 で発表したときのスライドです https://pycon.jp/2016/ja/schedule/presentation/41/
pep8 が pycodestyle に変わった話 - Qiita
概要 pep8 が pycodestyle というパッケージ名に変わってた Guido氏の提案が事の発端。 https://github.com/PyCQA/pycodestyle/issues/466 pycodelint という案も出てたが、pylint と区別がつかないので却下になってた 同時に pep257 も pydocstyle という名前に変わった https://github.com/PyCQA/pydocstyle/issues/172 自分の周りの影響範囲を軽く調べてみた。 追記(2018/02/27) ツール(ライブラリ)の pep8 の名前が pycodestyle という名前に変わったというだけで、PEP8 そのものには何も変更はないので気をつけてください。 pep8がスタイルガイドのPEP8と一緒だと混同しやすいのでツールは名前を変えようという話です。 pep2
Shibu's Diary: ソフトウェアの世界は螺旋を周りながら進歩している
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 npm周りでごたごたがありました。その前にはCocoaPodの問題もありました。その前にはGemの話も話題になりましたよね。 うんこれ。2年ぐらい前にnode.jsで開発していた時にも、node.jsのnpmのエコシステムいつか破綻するよなぁって思ってた。で、去年cURL as DSL作ったんだよね。Rubyのコード生成はまだないけどね。 https://t.co/1C0yw0KPib — 渋川よしき (@shibu_jp) March 6, 2016 上記のツイートはgemに絡んでのツイートであって、コンテキストはnpmではなかったのだけど、なんか予言めいたツイートに見えちゃったのかもしれないけど偶然です。ここまで、いくつかの文化の変化がありました。 SourceForgeや
Ruby/Pythonで依存パッケージをローカルインストールして開発環境構築やCIビルドを高速化する - Steel Dragon 14106
Ruby/Pythonで依存パッケージをローカルインストールして開発環境構築やCIビルドを高速化する By raimon, 2015-11-08(日), in category Git 一般的にRuby/Pythonで書かれたアプリケーションの依存パッケージはBundler/pipでインストールされるが、rubygems.orgやPython Package Indexからの取得・展開に時間がかかり、またこれらの中央サーバがまれにダウンしていると何もできなくなってしまうケースがある。 回避策の一つとして、依存パッケージをGitリポジトリに飲んでしまい、パッケージリポジトリとは通信せずローカルインストールで済ませる、いわゆるvendoring（ベンダリング）と呼ばれる方法がある。 サンプルリポジトリ それぞれのサンプルとなるGitリポジトリをGitHubに作成した。 ruby-local-g
『Pythonプロフェッショナルプログラミング 第2版』のWebアプリケーション課題をGitHubで作りTest PyPIで公開する - Steel Dragon 14106
『Pythonプロフェッショナルプログラミング 第2版』のWebアプリケーション課題をGitHubで作りTest PyPIで公開する By raimon, 2015-10-31(土), in category Python 秀和システムより出版されている『Pythonプロフェッショナルプログラミング 第2版』を読んでPythonパッケージングの仕組みなどについて勉強している。 2章「Webアプリケーションを作る」 3章「Pythonプロジェクトの構成とパッケージ作成」 で課題として登場するFlaskを使ったWebアプリケーションをPythonパッケージとして作成する方法について、書籍のサポートページなどからサンプルページを探してみたものの、見付からなかったので1から作ってみることにした。何点か書籍の内容に対してアレンジを加えたので、併せて紹介したい。 成果物 コード全体はGitHub、Py
Python製コマンドラインツールのディレクトリ構成について。その考察。 - カイワレの大冒険 Second
はじめに 去年ぐらいからPython製のコマンドラインのツールをいくつか作っていて、構成もだいぶ固まってきたので、まとめてみる。規模としては1ファイルでは終わらないぐらいで、関数の数も数十になってユーティリティを作ったり、クラスをいくつか作らないと、保守がしにくいような規模のものを想定しています。工数としては1日では終わらないけど、2週間はかからない程度の規模を想定。 構成 ということで、まず構成をさらしてみます。 こんな感じ。 SAMPLE_PROJECTレポジトリがあったとして、その具体的な構成が以下。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 . ├── README.md ├── RELEASE.md ├── TODO ├── bin │ ├── command1 │ ├── comm
The Node.js Community is Quietly Changing the Face of Open Source | caines.ca
The Node.js Community is Quietly Changing the Face of Open Source If you consider the number of packages on pypi, npm, and rubygems, and the release dates of python (1991), ruby (1995) and node.js (2009), it looks a lot like those communities are getting new packages at the following rates, per year: python: 29,720 packages / 22 years = 1351 packages per year ruby: 54,385 packages / 18 years = 302
「Node.js楽園の問題：npmという混沌」 - karasuyamatenguの日記
Drupal・DjangoからNode.jsに移ったが開発者がnpmモジュールの氾濫問題を指摘している： http://mikkel.hoegh.org/blog/2011/12/20/trouble-in-node-dot-js-paradise-the-mess-that-is-npm/ CSSやJavaScriptなどのアセットを圧縮してくれるモジュールが必要だったので調べてみたら、(推定)100を越える候補が出てきた。 管理されていないものを除外するなどの一次選択のふるいにかけても26の候補。(リストは元記事参照) Djangoなら明かな候補(asset-managers)があるのにNode.jsだと数十の候補を検証しなければいけない。このような時間をさくぐらいなら、自分で書いた方が速いと困惑している。 アセット管理だけでなく、routing、テンプレート、テストなど、Node.j
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://requires.io/