PyCon US Packaging Mini-Summit 2019

Last year at PyCon US, we had a “packaging mini-summit” to take advantage of the fact that many of us would be in the same room and try to get us all on the same page. I think that would also be a good idea for this year, and I’m wondering if maybe now is a good time to get started planning it.

Last year a decent chunk of the meeting was devoted to planning the agenda itself, should we maybe start getting the agenda-planning out of the way now, so that we can maybe figure out how much time we want to budget for the whole thing and how we want to structure it (working groups? Everyone in a big room like last time?).

Regarding attendance - here is an editable Google spreadsheet that we can use to track who is going to attend. We can switch it over to something else like a wiki later if that’s preferable.

In this thread, can we gather ideas of topics that should be covered during the discussion?

4 Likes

On a slightly tangential note, I think we should also put up the summary of whatever discussion takes place at the Mini-Summit somewhere, for people who aren’t attending the conference. (like me last year and not this year, hopefully).

1 Like

That’s actually on me - I have the notes from the meeting and never typed them up :frowning: I’m thinking I should post something soon-ish with the old agenda so that we can start building a new agenda from it, but it’s been a while so next year whoever does it should either be someone more responsible or a version of me that has learned his lesson about writing things up while they are still fresh.

3 Likes

I’m not quite a member of PyPA, but I will be around if you want to discuss integration in Linux distros (Fedora in particular), as an example of a larger project PyPA tools should(?) be easy to integrate with.

2 Likes

Paul - yes, I’d very much like the old agenda and notes so we can look at those and consider what we could do this year.

4 Likes

Is there any idea of what day or days this might be?

I imagine it depends on folk’s availability, but last year it was the first day of the sprints.

Last year we had a pretty well-attended open space (though I’m not sure it was as great a driver of “getting people on the same page” as I had hoped) during the conference, and the more structured mini-summit during the first day of sprints.

I’m guessing we may want to similarly split the “mini-summit” into two parts so that people who are main conference-only can participate, but we also get the somewhat more focused environment of the sprint day to have discussions.

Have we finalized the structure or dates+timing for the summit?

I propose we tentatively do something similar to what we did last year and have a split between the conference and the sprints, tentatively scheduling the “everyone in the same room discussing stuff” mini-summit for at least 1 hour in the morning the first day of the sprints, and at least one open space.

Last year I think we put a cap on the meeting on the first day of sprints at I think 2 hours. We can do that again, but depending on what we want to accomplish, it may be worth considering other structures. One option for this would be that we meet in the morning of the first day for ~1 hour and break into working groups, then throughout the day we each work on something, then either at the end of the day or the next day, we have another 60-90 minute session where the groups either give a recap of what they worked on or the working groups come back with any stumbling blocks that they want general feedback on.

One other thing I’d like to mention is that last year we spent a decent chunk of that first meeting enumerating topics and then voting on an ordering in which to discuss them. I think it would be a good idea if we could get that out of the way ahead of time (it would help with planning as well).

I don’t have time at the moment to set it up, but maybe we can have a thread here just for topic suggestions (no +1s or voting yet), and then after some hopefully sufficient period we can take a straw poll for what people want to talk about. That way we can try to budget enough time during the conference to get to the most important things, even if the final agenda is assembled by voting on the full list of topics on the day itself.

Anyone mind setting something like that up? I think the first part can be accomplished with just a topic selection thread on discourse and a cross-post to distutils.

I’ll do that.

1 Like

^made the topic suggestion thread

I’ll send a CTA for the topic suggestions, to distutils-sig tomorrow morning.


Meeting for ~1-2 hours on the first day, then breaking out into working groups sounds like a good way to structure the discussions.

There might be folks who can contribute to more than one working group but IMO it’ll probably be best to not have a person in more than 2 working groups at most.

I think we might also want to figure out how to structure the open space discussion. Would it make sense to have multiple open spaces, perhaps each targeted at a slightly more specific audience? An example of the top of my head is, one for discussing end user issues + one for publishers/redistributors?

1 Like

6 posts were merged into an existing topic: Packaging Mini Summit (PyCon US 2019): Topic Suggestions

Is there a way we could somehow all meet each other earlier in the conference so that we’ll be able to recognize each other during the conference days? That would make it easier for people to talk about packaging in advance of the first formal meeting if we run into people, etc. Otherwise, we could walk right by somebody and not know it.

2 Likes

By first day, do you mean the first day of sprints? Just trying to get a better sense of when things will be scheduled. Thanks in advance for your thoughts and helping put this together :smile:

I should be around and would love to discuss. If there are 2 topics or two ideas I’d like to propose it’s the following:

  • Possibility to enforce at upload time python_requires on PyPI; I believe it is important for people that are stuck on old python to don’t automatically get newer incompatible versions.
  • Ability to amend python_requires for already published packages – at least there are number of Python 3 only packages that where published without setting python_requires, and well once that’s done there is no fixing it pip2 will pull an incompatible sdist.

Edit moved to relevant thread.

Hello, rollback attacks…

1 Like

This is going to be critical. Can you please post this in the topic suggestion thread? One topic per reply as we’re leaving open the possibility of using “likes” as votes.

Edit: Honestly, I’d just put that as one topic, “Future of python_requires” or something, and then put as background that we want to discuss fixing bad uploaded versions and making it mandatory.

Edit 2: Here’s the issue on warehouse about making python_requires mandatory: Reject packages without a Requires-Python · Issue #3889 · pypi/warehouse · GitHub

Sorry, done.

Well, let’s discuss that separately, but I believe you already trust packages authors and run their code…