Log file Viewer

[03:23:50] <macopython> Rpm generated using setup.py bdist_rpm doesn't own directory. Need help for that.

[10:10:09] <thm> ronny: that's no fun with three different upstreams ...

[10:11:29] <thm> the whole python packaging thing is no fun - although it has become better :)

[10:12:41] <ronny> thm: yeah ^^

[10:13:48] <thm> so I am going to open a pip bug as well?

[10:21:11] <ronny> thm: as far as i understood the issue is entirely a pip bug

[10:26:10] <brechtm> Is it possible to preserve symlinks in an sdist archive?

[10:47:50] <ronny> brechtm: whats the use-case (usually its a bad idea)

[10:48:46] <mgedmin> something that involves Windows users never attempting to build from sdist, presumably

[10:49:25] <brechtm> :-)

[10:49:30] <brechtm> ronny: I'm linking a reference PDF file from my tests directory to my doc (Sphinx) directory, for inclusion as an example

[10:49:37] <mgedmin> oh yeah sphinx :(

[10:49:57] <brechtm> But I can just reference the PDF directly using the relative path from the :download: role.

[10:50:12] <mgedmin> I once wanted to include some README.rst's from my subpackages in my Sphinx toctree, had to create symlinks too :(

[10:51:15] <brechtm> mgedmin: and thanks for the quick check-manifest 0.32 release!

[10:53:37] <mgedmin> oh, that was you? what a coincidence :)

[10:55:39] <ronny> hmm

[10:55:47] <ronny> release automation helsp a lot ^^

[10:56:03] <ronny> i started to set up all my libs with setuptools_scm and a travsi ci pypi tag deploy

[10:56:09] <ronny> so every time i tag, bam release

[10:57:47] <mgedmin> fancy

[10:57:55] <mgedmin> I still use zest.releaser + makefile magic

[10:58:24] <mgedmin> @echo "now run python setup.py sdist bdist_wheel && twine upload dist/*" is also automation ;)

[10:59:33] <ronny> lol

[10:59:57] <ronny> for some time i was thinking of integrating setuptools_scm and zest

[11:00:10] <ronny> but it cant possibly work for more complex preps

[11:34:29] <nedbat> I'm trying to learn about signing PyPI packages, and wanted to see how the signatures appear on PyPI, so I figured I would look at the twine page: https://pypi.python.org/pypi/twine/1.8.1 I don't see anything about signatures there. Is twine not signed? Or I don't know what to look for?

[11:35:37] <mgedmin> signatures aren't really used today

[11:36:06] <nedbat> mgedmin: but twine's whole purpose is to sign packages, so i figured they would be signing theirs.

[11:36:43] <mgedmin> what? afaiu no, twine's purpose was to upload stuff to pypi securely, i.e. over https, and also with correct certificate validation

[11:37:15] <nedbat> mgedmin: ok, not the whole purpose, but it does claim better signing workflow as an advantage

[11:37:29] <mgedmin> there's no mechanism today for individual fle signature checking -- you can attach gpg signatures to uploads (or you could? wouldn't be surprised to learn it's been removed)

[11:37:33] <nedbat> mgedmin: cryptography seems to sign their sdist, but not the wheels: https://pypi.python.org/pypi/cryptography

[11:37:45] <mgedmin> but there's no automated validation and no knowledge of which gpg keys are supposed to be able to sign which packages

[11:38:03] <mgedmin> long-term plans involve adopting TUF

[11:38:17] <mgedmin> which is https://theupdateframework.github.io/

[11:39:13] <mgedmin> source: I'm (imperfectly, I'm sure!) relaying things that dstufft wrote to distutils-sig@ (and/or twitter, and/or blog)

[11:43:27] <nedbat> hmm, ok, so the intersection of packaging and cryptography is as confusing as you would expect... :(

[11:43:48] <nedbat> just seems odd that someone would build a tool with signing as a feature, and then not sign itself.

[11:44:11] <mgedmin> thread: https://mail.python.org/pipermail/distutils-sig/2016-May/028933.html

[11:44:46] <mgedmin> I think twine was replicating the existing features of python setup.py upload, which allowed gpg-signing

[11:54:18] <nedbat> mgedmin: thanks, this is very useful background.

[13:33:33] <rednovae> so i have an offline mirror of pypi, and when i run virtualenv i get 404 client error not found http://pypi.local/simple/pkg-resources . it looks like there is no pkg-resources pypi directory?

[13:38:15] <Wooble> rednovae: pkg_resources is part of setuptools

[13:38:16] <ronny> rednovae: correct, that package does indeed not exist

[13:38:39] <rednovae> ok, i figured it out. virtualenv from ubuntu repos was not working. using virtualenv from pip works, needed to add ~/.local/bin to my path

[13:58:45] <agronholm> why ubuntu does not do that by default is beyond my understanding

[15:50:23] <dstufft> nedbat: like mgedmin said, gpg signing on PyPI is not entirely useful, but the workflow provided by twine is slightly better for it :)

[20:38:36] <nanonyme> dstufft, btw, funnily enough other people got pissed enough at the situation at work that IT is now upgrading their devpi instance. Yay?

[20:40:13] <[Tritium]> http://www.infoworld.com/article/3047177/javascript/how-one-yanked-javascript-package-wreaked-havoc.html << it is really disturbing that someone else was able to get the package name and publish code

[20:41:07] <[Tritium]> imagine if he was malicious.

[20:41:51] <ngoldbaum> [Tritium]: did you see that the author of requests almost had his github account hacked?

[20:42:12] <ngoldbaum> only 2fa prevented his account from getting reset

[20:44:27] <[Tritium]> thats terrible, but it has no moral componant to the lifetime ownership of names on pypi

[20:44:52] <gsnedders> [Tritium]: to be fair, any naïve implementation of deleting packages will have that affect, so in a sense I'm not surprised more systems aren't vulnerable

[20:45:47] <[Tritium]> gsnedders: I dont /think/ you can delete a name off of pypi, and probably with good reason?

[20:55:04] <ngoldbaum> you used to be able to

[20:55:26] <ngoldbaum> i think it was turned off in 2014 or so due to these exact security and integrity concerns

[21:01:25] <dstufft> gsnedders: ngoldbaum [Tritium] No, you can still delete a name off PyPI, but you can't ever register a new file with the existing file names

[21:01:52] <dstufft> but you can register a higher version if someone deletes it

[21:02:08] <ngoldbaum> dstufft: ah sorry, you're right, i was misremembering

[21:02:17] <ngoldbaum> i tried to re-uplaod a botched release

[21:02:20] <ngoldbaum> didn't try deleting it

[21:03:57] <[Tritium]> ahh

[21:06:18] <dstufft> so we could still get leftpad-d

[21:06:52] <dstufft> but there's not a whole lot you can do to protect against an author willfully relinquishing their name, at a minimum they can always just transfer it to someone else

[21:18:10] <[Tritium]> I am in the camp of "names should never stop existing (unless extreme measures need to be taken for extreme situations)"

[21:19:01] <ngoldbaum> dstufft: I guess there needs to be a way to delete a release because of leaking credentials and other secrets?

[21:21:01] <dstufft> ngoldbaum: PyPI is a bit of a balancing act between restricting what authors do (to protect end users and give them consistency) and giving authors freedom (to give them the ability to make the choices that best suit their own individual projects). Author's delete releases for many reasons, some like that, some because it's broken and they don't want people to keep using it, etc.

[21:21:27] <dstufft> I personally feel that you should basically never delete a release, forwards is the only direction, but others have reasons

[21:22:59] <dstufft> Is the current situation the _right_ trade off? I dunno :) legacy PyPI went very far in the "go hogwild authors, do whatever you want" and a lot of what I've done has been slowly restricting that

[21:27:05] <ngoldbaum> dstufft: well i trust you to handle kik sending nasty legal correspondence to the PSF about some python project better than NPM did :)

[21:27:45] <dstufft> ngoldbaum: I don't handle them at all :) Legal shit I send to the PSF board (which typically means VanL) and I just do whatever they tell me

[21:28:04] <dstufft> we tend to be a lot more conservative though.