#i'm sorry for the tone in the previous

1 messages · Page 1 of 1 (latest)

visual reef
#

This is a bit of a meta discussion, so not really appropriate in #pip , but yeah this is not a private space to vent on a topic.

We should strive to communicate like we are all in the same room face to face talking, and anyone's work we are talking about might join in at any time.

If something is incorrect it's okay to call it out, but we all need to be aware not to assign bad intent or use expletives to describe someone's work.

Text can be corrected in official documents if it is wrong, but it is worth assessing how much it actually matters if it's correct or not, like what are the practical implications and how many people are even going to read the specifics.

ember glade
#

i am not going to use this space for that and i'm sorry

visual reef
#

I'm not a great communicator myself, and often get stuck in the details and frustrated by others. So I understand it.

I recently wrote out a post that I knew was being snide to someone, I walked away for a bit before posting, then came back and deleted it, ahah.

ember glade
#

i can make sure this space is a useful place to collaborate. that is indeed the space i want to help build

#

thank you for engaging

#

i'm working on a zstd rust implementation now. it's a very configurable format to domain-specific requirements in a way that allows decoders to remain simple and safe

gritty temple
# ember glade i can make sure this space is a useful place to collaborate. that is indeed the ...

I'm not sure if you saw my message from a while ago, but I'm willing to talk generally about how to get changes landed in pip and in the broader packaging ecosystem.

Forewarning, this is unsolicited advice and feel free to ignore it, but something I've learned is that it's so super duper important to get stakeholder buy-in before you embark on major proposals. You can have an amazing proposal that will fix world hunger all the bugs, but if the change is too complex and you don't have buy-in, you're going to struggle to get your proposal over the line. It doesn't matter if it's the most technically brilliant and obvious improvement, very few decisions in open-source are of a purely technical nature. There are always other considerations: maintenance cost, aversion to risk/change, inertia, social pressure, etc.

I once worked on a large PR to parallelize bytecode compilation in pip. I spent quite a bit of effort on it and got it to a state that was close to production ready, but it ultimately fizzled out because I did not get buy-in from the rest of the pip core team. Yes, that sucked, but ultimately, pip is a collaboration. I can't just have my features and change applied without considering the point of views of the people I'll be working with. I've since stuck with feature proposals that are easier to sell or already have buy-in. Yes, progress is more incremental, but it's actually happening, vs not at all.

If you're starting something new, then of course this doesn't apply since there aren't any stakeholders anyway, but for contributing anything to community open-source, you do ultimately need to sell it to the maintainers.

I know you likely disagree with Brett Cannon's POV, but I do consider his post on setting expectations in open-source to be a great piece on the human dynamics of open-source contributions: https://snarky.ca/setting-expectations-for-open-source-participation/#submittingacontribution

ember glade
#

that was my first contact with the project

gritty temple
#

Yeah, I wasn't around during those years

ember glade
#

i had already gotten an earlier change merged

gritty temple
#

On that front, all I can say is I apologise for that. Pretty much none of the stakeholders from there are still active, minus Paul.

ember glade
#

something changed and i could no longer get anyone to review my PRs

#

ofek lev was credited by brett cannon in PEP 751 and he was pretty active in the threads where i got stakeholder support

#

i am deciding mostly to stop being upset and to move on because it's pretty clear things are not going to change

gritty temple
#

Right, that does suck. I can't really comment on that given I was not involved in PEP 751, etc. etc.

ember glade
#

not trying to make it anyone else's problem. your work seems genuinely good and i feel wistful when i see your PRs. wish i could motivate myself to work on the packaging library

#

really glad you're doing it

gritty temple
#

I don't work on packaging FYI

#

I'm not Damian

#

:P

ember glade
#

god sorry

gritty temple
#

I'm not as technically competent as that guy

ember glade
#

i'm just glad someone is investing into it

gritty temple
#

I guess you don't know me then. I am the newest pip maintainer, joining around 2023

ember glade
#

i have no problem with astral profiting off of it. i applied to them

#

abusing the PEP system to make false claims is deeply untrustworthy and brett cannon's particular distaste for the one PEP written by a woman is really blatant

#

he also filled PEP 658 with similar forms of snide comments. deeply unprofessional and that time he was insulting me personally

gritty temple
#

I'm going to push back a bit on that. PEP 566, which I think you're referring to, was arguably too modern for the time.

#

There are renewed conversations on finally using JSON for core packaging metadata.

ember glade
#

he's gone way above and beyond that. i'm not talking about at the time. i mean long past that. there are these ridiculously harsh comments about the PEP before 566 in the packaging library's source code

#

he also really really really does not want METADATA to be machine-readable through JSON which is directly codified in PEP form which i also find deeply untrustworthy. https://pip.pypa.io/en/latest/reference/installation-report/ i thought with this i could change the world. brett cannon thought otherwise

gritty temple
#

We aren't really standardizing pip features anymore. pip's report is meant to be a machine report... well report of what pip installed or will install (dry-run)

ember glade
#

now that i'm seeing pip is moving to PEP 440 for building code and that the wheel format is going through PEP 777 it's true that i won't need to contribute to pip which is a project that i liked to contribute to (if you watch my talk video you'll see how much i describe loving to work with the project)

#

or maybe 440 is the wheel naming one

gritty temple
#

Oh hmm, I guess I wasn't aware of that background. I was only aware that Stéphane had contributed pip install --report.

ember glade
#

is that what people say?

gritty temple
#

That?

#

Sorry, I'm a bit confused

#

PEP 440 is the naming/version standard, no? (yes, the fact we use numbers is not at all confusing)

gritty temple
ember glade
# gritty temple Oh hmm, I guess I wasn't aware of that background. I was only aware that Stéphan...

i'm quite upset that the impression is that stéphane was responsible for the installation report feature. he contributed a single PR which reworked mine and made very minor changes over the question of whether to put it in the download or install commands. i liked his work and was glad for it. it was a cosmetic layer over the previous several PRs i had contributed. i trusted his judgement as a maintainer and he had helped to ensure it conformed to e.g. PEP 566 JSON. i'm glad i shouted him out at the conference talk.

gritty temple
#

In fairness, this is with my pip maintainer hat on. I have no idea how the feature is perceived in the wider ecosystem.

ember glade
ember glade
gritty temple
#

Seems like a reasonable take

#

pip isn't cool anymore and we don't market our new features.. like at all

#

My pip release posts are a half-arsed attempt at doing the bare minimum to provide commentary on new pip features, but it probably definitely doesn't really move the needle.

gritty temple
# ember glade i don't believe anyone is aware of it

On a more practical note, I think your pip fork is a nice idea. It's a project where you can do whatever you want and explore your technical vision. With the right branding and marketing, it'll clearly be yours.

gritty temple
# ember glade given that astral claims credit for the zip file work i did which began as "fast...

Right, on pip's end, it is really just a matter of bad timing and competing priorities and maybe not as great project management (not singling anyone out, but I can personally say that I've said that I would review something and then just forgot to get around to it). I'm not trying to dismiss your feelings. I'm sure for you it does suck, and if I were in your shoes, I'd feel the same way, but there were no malicious intent on our part FWIW.

gritty temple
ember glade
gritty temple
#

Okay. I'm just trying to leave the bridge hopefully not burned forever!

#

FWIW, I do wear the pip maintainer hat and also admin hat for this server, but I am not speaking authoritatively for the ecosystem. I'm just speaking my mind as someone is also interested in Python packaging and is trying to make it better in their own way.

ember glade
gritty temple
#

Sadly, it does happen beyond in software :(

#

It also happened to hatch, not intentionally, but just because astral's projects have consumed most of the airwaves in Python packaging. AFAIU, Hatch did innovate a bunch, but many features got credited to other tools because they were generally more prominent in public discourse.

#

Just an natural consequence of users talking about what they are experiencing. If they all use tool X, then naturally the discourse will revolve around said tool X.

#

I wish I had a solution to propose, but uh, I don't.