Questions for Python Developer Survey

Packaging
21

Thank you. These questions require further discussion before including them in the survey.

22

Thank you for the feedback.

1 Like
23

Thank you. The answer choices will be updated.

1 Like
24

I think Poetry should be listed in 8. It’s difficult to gauge its share (since it can be used for both library and application management), but I suspect it’s not far behind Flit. It may be tricky to get users to correctly assess whether they are actually using Poetry for libraries or applications though. Maybe it’d help to say something like “build libraries for publishing to a package index, such as PyPI”.

1 Like
25

I’m inclined to think we have better data sources for this (such as, well, PyPI :wink: ).

Perhaps the more interesting part of this question is to test the premise: do people even publish packages? And if not, why not? (Don’t want to // don’t need to // don’t know how to // not allowed by employer // etc.)

3 Likes
26

I would add:
e. conda-forge
f. Anaconda
g. Linux distribution

Perhaps add:
f. conda-build

1 Like
27

Thanks a lot for doing this! I’m really looking forward to see how this turns out.

Q13: It might make sense to also have a catch-all for open source tools – possibly an open-ended field to specify them. That way, we could get noisy-but-useful inputs about lesser used workflow tooling.

Q8: poetry also has this functionality, and is popular enough that it should get added here.

Q2: This seems a bit odd to me, as currently phrased, since it doesn’t touch upon the nuance that the files are for significantly different things. Notably, pyproject.toml feels out of place, since it can be used to configure tools like mypy, black, isort etc but can also contain project metadata (eg: if you’re using flit or poetry). Without separating those uses, there’s going to be a strong bias toward that. OTOH, if we remove that, then it seems to me that Q3 would provide more clear data about users’ tooling choices.

Update: I just realised it’s the only question that gives us insight on pyproject.toml adoption though!

Q5: I think it’d be a good idea to avoid mentioning setuptools – just “easy_install” for that option should be sufficient – it would reduce potential for users to tick that option because they remember writing setuptools for imports in their setup.py and dependency specifications.

Q10: Maybe the phrasing should be changed to something along the lines of “Have you published a Python package to a package repository?” – “published packages” seems very vague on a first read. It might make sense in context though.

I agree with @steve.dower that getting licensing information from this survey isn’t super useful or relevant. I don’t think knowing the relative popularity of licenses is useful for improving Python or related tooling. If it’s not published publicly, there isn’t much value in asking what license it has. And if it has been published publicly, this information is accessible via the metadata that it has.

3 Likes
28

Thanks for putting this together and asking for feedback! :clap: :+1:

Even if poetry is using pip under the hood, I would still include it (poetry) here. The same goes for pip-sync (part of pip-tools).
Then finally, I’m wondering if pipx has a home here.

Doesn’t GitLab have something too for hosting packages… and I know Artifactory has PyPi repos.
Also, in 10, you have “Internal Python Package Index”, which perhaps is something which should be reflected here.

Maybe twine should be listed here.

Finally, I’m wondering if you want to include a question about using pyproject.toml with a build system. Maybe a sharp niche edge case that isn’t worth asking about.

1 Like
29

#1. b. No
#4. c. No, application dependency is updated manually
#5. a. pip
#6. a. PyPI
#7. b. No
#9. b. No
#11. b. No
#12. Do not use.
#13. a. pip

1 Like
30

Question 8: flit and poetry should be added to the list, not left as write-ins
Question 12: “I don’t, I use the virtualenv package” should be an option.
Question 13: flit should be added

2 Likes
31

Thank you for sharing the questions and asking for feedback.

Would it be worth trying to distinguish between library and application developers here (or somewhere else in the survey)?

When I read “application” I think something like “deployed web site” and I would guess this is the main target audience of pipenv and poetry users.

I use poetry but for open-source scientific software library development – i.e. a tool that other researchers can use in their own code.

Sorry if this is covered elsewhere in the survey but since I see similar comments e.g. from @uranusjr

maybe it is worth tweaking the wording or adding questions to be clear about “application” v. “library”

2 Likes
32

For Question 8 may I also suggest maturin and pdm-pep517? From my (as yet unpublished) data crunching of build backends on PyPI they seem reasonably popular.

33

Last minute:

  1. a
  2. a
  3. c
  4. a
  5. ab
  6. a
  7. a
  8. ca
  9. a
  10. a
  11. b
  12. a
  13. aei
34

Thank you to everyone who has contributed to this thread. Most suggestions have been added to the final set of questions. I look forward to your responses once the Developer Survey is released in a few weeks.

3 Likes
35

@nicholdav @uranusjr I have modified the questions to differentiate application/library development. Please could you review questions 11-18. Are there other questions in the current list that could have different answers depending on application/library development? Also, please suggest any new questions.

1 Like
36

Hi @smm thank you for integrating our feedback.

I might be the least qualified to answer – I’m sure @uranusjr and others have better ideas.

But for me the use of the word “development” is a little confusing in the questions.

I might word it like so:

Do you create distribution packages for applications, for example, to upload to PyPI or to share internally? (There are separate questions on packages for libaries below)

and then similarly …

Do you create distribution packages for libraries? (yes/no)

I suggest the term “distribution packages” since that’s what’s used for clarity on packaging.python.org. I think that’s what the survey is trying to get at here. If I’m misunderstanding then feel free to disregard.

37

Thq questions have been modified. Please let me know if it is better now.

1 Like
38

:+1: Looks good to me

39

Thanks @EWDurbin , that will be useful information for me.

40

This should probably be multi-choice - I know I use different systems on different projects. Probably also worth distinguishing “Custom tools, e.g. a cron job or scheduled CI task” from “No, application dependency is updated manually”.

And as with many others, thank you for getting community input into the survey design!

1 Like