Log file Viewer

[10:35:55] <GPF> hello, is there a way to pass pip options that are passed down to a configure script that runs while pip is compiling some C extensions?

[10:36:51] <GPF> background: I want to compile python net-snmp bindings on OS X and it fails with "duplicate symbols" C error while linking. I want to pass --disable-shared to the configure script of the net-snmp bindings

[15:18:38] <marsje> Hi. I'm trying to make a python package that installs a config file into /etc but I can't get it working. Is it even possible?

[15:21:15] <ngoldbaum> i don't think so

[15:22:40] <marsje> the example here sorta implies it's possible I think: https://docs.python.org/3.4/distutils/setupscript.html#installing-additional-files

[15:24:03] <ngoldbaum> wouldn't you need root?

[15:24:52] <Wooble> marsje: it's generally not considered a good idea to require users of your package to install as root...

[15:25:31] <ngoldbaum> and you'd need to install as root using your python, not root's python

[15:25:37] <marsje> Wooble: well, it's a company internal script and I will probably the only one to use it, but you are right

[15:26:35] <Wooble> I'd probably prefer a .deb or whatnot over data_files in that case anyway.

[15:26:41] <marsje> ngoldbaum: yeah, I'm using sudo to do the install, and run

[15:27:38] <Wooble> (although possibly data_files is the right way to get bdist to put the files there when it builds the package-manager package)

[15:27:45] <ngoldbaum> marsje: so i guess the conclusion is that you can, but it's probably not a good idea. If you are the only person installing this package then go ahead, but whoever needs to do it next time will scratch their head about why this one particular package needs to be installed as root

[15:27:48] <marsje> Wooble: the pip package is meant as a better version of copy/paste, so creating a deb would be a bit overkill I think

[15:28:19] <ionelmc> marsje: data_files is handled inconsistently

[15:28:46] <ionelmc> https://github.com/pypa/pip/issues/2874#issuecomment-109429489

[15:28:59] <marsje> ngoldbaum: but the script needs to be run as root, so installing it as root is maybe needed?

[15:30:38] <marsje> ngoldbaum: it will be run as a upstart service

[15:32:00] <marsje> ngoldbaum: actually, Wooble is right and it should be a deb... I now have an install option in my script that creates the upstart script. I guess I can extend this to also install the config file

[15:32:30] <ionelmc> marsje: you definitely want an system package if you're dealing with services

[15:36:11] <marsje> ionelmc: that would be the best solution, technically, but not time-wise :)

[15:37:14] <ionelmc> marsje: shoehorning is definitely not time wise

[15:37:18] <ionelmc> you waste more time in the end

[15:40:49] <ionelmc> now you have learned two things :-)

[15:41:58] <marsje> haha

[15:43:07] <ionelmc> marsje: check https://github.com/spotify/dh-virtualenv or https://github.com/paylogic/py2deb

[15:43:26] <ionelmc> though i haven't used them, good luck :D

[15:44:13] <marsje> py2deb sounds interesting

[15:49:15] <ionelmc> meshy: https://github.com/jordansissel/fpm (also not used)

[15:49:33] <meshy> um... hi

[15:49:38] <meshy> :)

[15:50:39] <gchristensen> fpm is pretty rockin'

[15:50:53] <meshy> ionelmc: I starred that a couple of days ago :) -- I think I got it from a blog post

[15:51:30] <ionelmc> meshy: we were talking about shoehorning

[15:51:37] <ionelmc> some people like to call that packaging

[15:51:39] <meshy> aha -- was from here: http://www.doismellburning.co.uk/talks/django12factor/

[15:51:56] <meshy> (slide 21)

[15:52:19] <meshy> shoehorning :D

[15:58:13] <ngoldbaum> ionelmc: it's free for the taking :) https://pypi.python.org/pypi/shoehorning

[16:01:19] <ionelmc> zomg what to put there

[16:01:59] <ionelmc> some special kind of evil perhaps

[16:56:38] <agronholm> is login supposed to work on warehouse

[16:56:46] <agronholm> I get 400 Bad CSRF Origin

[17:03:40] <dstufft> agronholm: There's a bug with Pyramid 1.7a1 and CSRF that's fixed in master but hasn't been released yet and I haven't taken the effort to pull in from master yet

[17:04:07] <agronholm> aww, ok

[17:07:37] <dstufft> I could probably work around it pretty easily I guess

[17:20:40] <[Tritium]> I don't know how to articulate how much of a bad idea it is to even entertain the idea of revoking one user's use of a pypi name and giving it to another...

[17:21:36] <ngoldbaum> [Tritium]: what triggered that?

[17:21:42] <[Tritium]> Who in the PSF wants the job of arbitrating THAT storm...

[17:22:02] <ngoldbaum> ah, distutils-sig...

[17:22:07] <[Tritium]> ngoldbaum: one of the mailing lists... disutils-sig i think (could have been -ideas)

[17:22:18] <ngoldbaum> from guido no less

[17:22:27] <Wooble> [Tritium]: it's really awful that mypy didn't check if someone was using the same first. :/

[17:22:49] <Wooble> (also, as someone pointed out, that's a horrible named to begin with...)

[17:22:55] <[Tritium]> You know what I do before I finalize my package names? .... i check pypi

[17:23:21] <[Tritium]> Its like calling your company yahoo.com and then get upset that yahoo.com is taken

[17:27:43] <ngoldbaum> [Tritium]: yes, people talking about python package names expiring like domain names scares me a bit. Seems like a great recipe for someone malicious to take over a popular, but unmaintained package like pyyaml

[17:28:06] <[Tritium]> I said that just now on the list!

[17:28:14] <[Tritium]> well.. 20ish minutes ago

[17:28:43] <Wooble> speaking of which... can we get someone non-malicious to take over pyyaml? :)

[17:29:19] <[Tritium]> ikr

[17:31:13] <dstufft> I do not think it's likely we will ever auto expire anything.

[18:35:23] <ngoldbaum> [Tritium]: "until the heat death of the universe

[18:35:24] <ngoldbaum> or the death of the language whichever is first."

[18:35:36] <ngoldbaum> i see you're bullish on the long-term prospects of Python :)

[18:35:45] <[Tritium]> Yus

[22:13:47] <dowwie> dstufft: searching 'yosai' returned zero hits in pypi :-/

[22:14:19] <dstufft> dowwie: yea, search is half way busted on legacy pypi :[

[22:14:27] <dstufft> I'm working on getting warehouse ready to deploy though

[22:14:28] <dstufft> https://warehouse.python.org/search/?q=yosai

[22:14:30] <dowwie> dstufft: this is all your fault!

[22:14:40] <dowwie> woo !

[22:14:46] <dowwie> when are you flipping the switch

[22:16:03] <dstufft> dowwie: unsure exact date, but legacy is bitrotting so we're going to deploy warehouse but keep legacy around on a subdomain for the features we don't yet support

[22:56:32] <ionelmc> dstufft: what features are those?

[22:58:15] <dowwie> dstufft: are you satisfied with the authorization policy or looking for more granular, permission-level authz?

[23:09:01] <dstufft> ionelmc: mostly the web ui for editing accounts and projects

[23:09:37] <dstufft> dowwie: current authz blows, but probably isn't going to change until legacy is retired because I have zero interest in trying to wire up a new authz system into legacy code base