Log file Viewer

[00:01:05] <jrabbit> MrJones: probably not?

[00:01:22] <jrabbit> MrJones: but you can set it up elsewhere and then reference that folder

[00:22:38] <MrJones> jrabbit: how so?

[00:23:25] <MrJones> I'm talking of the pip3 install <remote git repo> it's not like I can set up anything when doing that

[00:43:44] <jrabbit> download the repo init the submodules then pip install -e the_folder

[00:46:52] <jrabbit> oh it mgiht work with submodules did you not try it???

[00:47:11] <jrabbit> took me 3 minutes to look at prs

[00:56:39] <jrabbit> MrJones: the gist i got is if it's simple submodules it ought to work

[01:09:22] <MrJones> jrabbit: ohhh that would be nice

[01:09:41] <MrJones> anything manual doesn't help me it's supposed to work as a dep, but if it just works that'd be awesome of course

[01:10:52] <MrJones> I've been putting together a build to test during the last hours so I'll see soon

[01:23:27] <jrabbit> requirements.txt isn't automatically processed?

[01:34:33] <MrJones> I'm not even sure what you are talking about :D but I may have explained myself badly

[01:35:00] <MrJones> sadly I've been stuck on other parts of the build so I don't know what pip actually does with a basic git submodule yet, I'll let you know once I found out

[01:53:33] <MrJones> does newest pip use special ansi codes to rewrite the output?

[01:54:00] <MrJones> because it actually seems to erase parts of it making it all kind of hacked up, and I can't see the actual wheel build error

[01:54:11] <MrJones> is there a way to disable this? pretty sure earlier versions didn't do that

[03:40:15] <pradyunsg> MrJones: pip does rewrite output of it's progress bars. You can use --no-color to disable colors and --progress=off to disable the download progress bar.

[19:00:34] <sumanah> tos9 and other New York City people: last year https://www.meetup.com/nycpython/events/249722192/ a Warehouse hack night got dozens of people, most of whom were new to packaging

[19:01:06] <sumanah> if we did something again that was specifically "packaging is not magic, here is how to make your first package" I bet a bunch of people would turn up

[19:02:15] <tos9> sumanah: posssssibly we should chat about hosting that

[19:02:45] <sumanah> tos9: cool! who is "we" in this context?

[19:02:47] <tos9> sumanah: Who did you work with at NYCPython there? Jon?

[19:03:19] <sumanah> tos9: Laura Hampton talked with folks from NYC Python and PyLadies.....

[19:03:22] <sumanah> checking.....

[19:03:52] <sumanah> Reshama and Sam?

[19:04:25] <tos9> Man, been too long on not keeping up on NYCPython, since I recognize neither of those names.

[19:04:34] <tos9> sumanah: But I *likely* can offer a space

[19:04:41] <sumanah> well it could be that both of those are not so much NYCPython names as PyLadies names?

[19:04:56] <sumanah> tos9: remind me -- what organization/building/company is your space affiliated with?

[19:05:01] <tos9> sumanah: Do you want to take this to email / do you need me to talk to NYCPython or do you think someone else can do that part?

[19:05:04] <tos9> sumanah: Deloitte

[19:05:23] <sumanah> tos9: hey if you want to throw a packaging night I can turn up! I do not need to be the person to organize this :)

[19:05:34] <sumanah> I'm inspired here by https://wiki.debian.org/DebianNYC/Workshops/3 which was a useful Debian NYC workshop I attended 9 years ago

[19:06:28] <sumanah> https://packaging.python.org/tutorials/packaging-projects/ is tested and pretty good

[19:07:52] <sumanah> the only problem I have run into with it, in the past 2 years of using it to help people learn to package Python projects, was that there was one guy at the sprints at PyCon who didn't like that he had been given "here's how to package your first project" onramping rather than "here are the Advanced Options so you could hook everything up to your CI for continuous release with minimal input from you"

[19:08:55] <sumanah> I imagine that it would be good to set those expectations appropriately for an NYC "how to package" night -- probably way more appropriate to optimize for beginners who need onramping and not the "I want to dive into the super complicated deep end right away" folks

[19:11:17] <sumanah> tos9: if you decide you'd like to push this forward and you'd like me to be a helper, tell me some dates that might work for you and I'll let you know which subset of them will probably work for me

[19:14:01] <tos9> sumanah: yeah that works! I'll have to dig a bit and get the calendar, and then will probably loop in organizers + you + whoever else might be able to make it

[19:14:22] <sumanah> tos9: cool! feel free to start a discuss.python.org thread

[19:14:31] <sumanah> thanks tos9!

[19:16:44] <sumanah> tos9: (Based on my experiences the last few days, it seems good to separate out the "teach beginners how to use existing tools" workshop from a "let's hack on stuff" sprint afternoon or night; I could be wrong)

[19:25:21] <tos9> sumanah: yeah agreed -- I'm likely more interested in the latter than the former, though the former is more likely to get decent attendance I suspect

[19:32:34] <sumanah> tos9: I would guess that roughly 20% of the packaging beginners would then be interested in working on the tools in a Part II kind of hack night

[19:37:22] <sumanah> tos9: and I would consider 6-15 people actually a totally reasonable and successful number for a "let's hack on stuff" sprint afternoon or night. because the event provides scaffolding and face time for those people and does help move the project forward, and provides a sufficient delta compared to the alternate universe where the event hadn't happened