#pyramid

dstufft: Hes complained a lot about that via twitter, I forget the reason exactly but I think "python 3" sums it up

sontek: yea it's python 3 issues

but I can more or less handle those issues myself, I just wish i could make click not be a nanny in that situation ;)

ree: I am no claiming I know what is better, but that to me is not readable

goodwill: I think the decorator model works really well because it allows you to combine commands easily

goodwill: I haven't seen a cleaner API for building CLI tools

goodwill: honestly I'm not sure I can think of a situation that's better if you want to have half a dozen flags

I usually just build a factory to wrap ArgParse

again, I do not claim I know better

I mean argparse itself is roughly the same number of lines

but to me click way of doing it ... is unreadable

and you mix up parser defintion with the actual method that does things

goodwill, allright, I think I understand what you don't like, but then I am not sure what alternative there is

that's better

ree: I just do not think having multiple decorators that wrap each other is a good pattern like this

or readable

the same thing without all the @ signs

clearly it is a personal preference

;)

(I do appreciate a lot of the little things click gives me, like having it force you by default to add an option to inverse a boolean flag

goodwill: You don't have to use the decorators, you can use `add_command` as well

like the way you make a boolean by default is --true-thing / --false-thing

just building up a commnd object over a few calls is what that's doing, but you can't see the comand object in the middle

just when you get to the end

you don't really ever see the command object

I do not even see add_command in the docs

I am sure it is somewhere

I guess I've seen too much code wrapped with multiple decorators and those decorators being giant and unsupportable

He even has really good built in testing support for it

I'm half way considering trying to move pip to use click :3

although the LC_ALL=C thing is a bummer for that

dstufft: any thoughts about peep?

goodwill: good project, sooner or later I want to add that functionality to pip itself

though I think it'll require a new requirements.txt language

I mean signage alone is awesome

stuffing more things into the current one is kinda gross

prolly

on the "lets add cryptography into packaging" front, PEP 458 is probably a thing that's going to happen

sontek: I do not even see add_command in click docs search

ah found it

there not examples for it

which will enable better verification of things you downloading from PyPI (no longer requiring to trust the CDN or mirrors)

and considering the current events, this sounds like a darn good idea

right

you still have to trust the servers that we run for PyPI, and you have to trust shady people like myself who run PyPI :D but other random people no

better to do that before the nsa decides to poison packages in the cheeseshop

:-P

dstufft: well assuming there could be other PyPi's

the NSA can probably seize the servers that run PyPI since they are on US soil

dstufft: have you decided what you want to use yet?

meh, I don't trust libcrypto so I think we're mostly doomed at this point ;)

this reminds me

welcome to Russia my fellow Americans ;)

they won't seize it, they would inject malicious code into packages.

goodwill: nope! I didn't mess with it much since earlier today. I've been working on getting pypi-legacy to stop using the filesystem to store packages and start using an object store

which is how they infiltrate enough machines on the net for their operations

so that I can make warehouse not need to run on the same machines ;(

dstufft here is considering writing next PyPI maybe in Pyramid ... I say we group hug him to make it easier for him

:-D

sounds like a good choice ;)

woha, pypi currently exists on a single file system?

gavinc: wellllll

it's a horrible glusterfs cluster

heh

it's 2x glusterfs nodes which are mounted via FUSE on x3 web nodes, with x2 8GB RAM/SSD boxes running postgresql

my plan is to move to using multiple mirrored object stores for the package files (and eventually the installer API alltogether) and have fastly hit the object stores directly

so that ``pip install whatever`` does not rely on moving parts on our end

+1 more URLs, less file handles

devpi already uses pyramid so might as well keep the trend going

(although I wouldn't use them as a model pyramid project)