Mailman 3 October 2014 - Distutils-SIG

toml
by Daniel Holth 28 Oct '14

28 Oct '14

Learned about toml the other day, looks like it could be useful for packaging. It is an .ini-style language that maps unambiguously to a dict, supports comments, and is used by rust's packaging system "cargo". https://github.com/toml-lang/toml Unfortunately at least 3 of the Python implementations don't seem to be up to date with the current version of the spec specifically regarding triple-""" strings.

6 8

twine: Binary wheel for an unsupported platform
by Antoine Pitrou 28 Oct '14

28 Oct '14

Hello, I guess I am doing something wrong, but what? (I took "linux_x86_64" after PEP 427 and 425) $ twine upload dist/llvmlite-0.1-py2.py3-none-linux_x86_64.whl Uploading distributions to https://pypi.python.org/pypi Uploading llvmlite-0.1-py2.py3-none-linux_x86_64.whl Traceback (most recent call last): File "/home/antoine/.local/lib/python3.4/site-packages/twine/commands/upload.py", line 228, in main upload(**vars(args)) File "/home/antoine/.local/lib/python3.4/site-packages/twine/commands/upload.py", line 183, in upload resp.raise_for_status() File "/home/antoine/.local/lib/python3.4/site-packages/requests/models.py", line 825, in raise_for_status raise HTTPError(http_error_msg, response=self) requests.exceptions.HTTPError: 400 Client Error: Binary wheel for an unsupported platform During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/antoine/.local/bin/twine-upload", line 11, in <module> sys.exit(main()) File "/home/antoine/.local/lib/python3.4/site-packages/twine/commands/upload.py", line 230, in main sys.exit("{0}: {1}".format(exc.__class__.__name__, exc.message)) AttributeError: 'HTTPError' object has no attribute 'message' (also note the Python 3 buglet in main() above) Regards Antoine.

3 2

Making a wheel platform-specific?
by Antoine Pitrou 28 Oct '14

28 Oct '14

Hello, I am trying to package a project which has the following features: - pure Python code (2- and 3-compatible) - no C extensions (therefore no CPython ABI issues) - but there's a .so file (or DLL) that's loaded at runtime using ctypes (FYI: https://github.com/numba/llvmlite) I would like to tell bdist_wheel to therefore tag the package as a Python-independent, platform-dependent binary package. There doesn't seem to be a way of doing so, or is there? Regards Antoine.

4 9

depending on setuptools is discouraged?
by Michael Merickel 25 Oct '14

25 Oct '14

I'm noticing a trend that depending on setuptools is discouraged[1] in the install_requires of your setup.py. However, some packages like pyramid have core features that depend on pkg_resources (which is part of setuptools). Thus, we depend on it. As I've monitored distutils-sig I haven't seen any talk of separating these packages. To me, requiring the use of pkg_resources is a very valid use-case for depending on setuptools as it provides many improvements over the basic `pkgutil.get_data` API. Since I'm not aware of a workaround for this problem, and I'm seeing setuptools be categorically discouraged, perhaps I am just unaware and need to be enlightened? Thanks! [1] https://mail.python.org/pipermail/distutils-sig/2014-October/025131.html

5 6

devpi-{server-2.1.2, web-2.2.1}: bugfixes, streamlined web templates
by holger krekel 24 Oct '14

24 Oct '14

devpi-server-2.1.2 and devpi-web-2.2.1 bring a host of fixes to the private pypi server system. You can upgrade without migrating your data if you run already with devpi-server-2.1.X. Find docs as usual at: http://doc.devpi.net Many thanks to Florian Schulze who did most of the changes in devpi-web. Have fun, holger krekel, merlinux GmbH devpi-server-2.1.2 ------------------ - fix issue172: avoid traceback when user/index/name/version is accessed. - fix issue170: ensure that we parse the prospective pip-6.0 user agent string properly so that using the username/index url works with pip. Thanks Donald Stufft and Florian Schulze. - fix issue158: redirect to normalized projectname for all GET views. - fix issue169: change /+status to expose "event_serial" as "the last event serial that was processed". document "serial" and "event-serial" and also refine internals wrt to "event-serial" so that it means the "last serial for which events have been processed" devpi-web-2.2.1 --------------- - require devpi-server>=2.1.2 - fix issue175: use normalized name of projects, so redirects from unnormalized names works. NOTE that if you had issues with documentation uploads not appearing because of normalization issues ("-" or "_" appearing in the name for example) you need to re-upload the docs or do a full export/import cycle. - fix view when tox results can not be parsed. - version.pt: removed "code" tag around overwrite count. - macros.pt: added "footer" tag around the whole footer part. - version.pt: moved file type, python version and size info from their own columns into the file column. - version.pt: moved history column from before the tox results column to behind the tox results. - version.pt: removed "last modified" from history column - version.pt: removed timestamp from "replaced" action in history column - version.pt: add link to PyPI page if applicable. - fix project page view if there are downloads with filenames which can't be parsed as packages with version number - fix notfound-redirect when serving under an outside URL with a sub path

1 0

Where is distribute at pypi?
by Rupert Kolb 23 Oct '14

23 Oct '14

Hi, where is the distribute package at pypi? There is software (for instance pydicom) which need the distribute-0.6.xxx package. It doesn't work with the "setuptools" replacement out of the box! You can not just remove it!? Rupert

3 2

stdeb and python dependencies
by Kelly Goedert 23 Oct '14

23 Oct '14

Hi, I am new to python. I created a simple python cli application that depends on jsonpickle and plumbum. Using this command python setup.py --command-packages=stdeb.command bdist_deb I was able to create a .deb package. But when I try to install the package with dpkg -i package_name I get package_name depends on python-plumbum; however: Package python-plumbum is not installed. package_name depends on python-jsonpickle; however: Package python-jsonpickle In my setup.py I have this: dependencies=['plumbum','jsonpickle'] install_requires=dependencies Is it possible to make the debian package install this python dependencies? Or is this the wrong approach? If so, what would be the recommend way? Thanks Kelly

2 1

Hobby time (was: some questions about PEP470)
by Ian Cordasco 17 Oct '14

17 Oct '14

On Oct 16, 2014 4:47 PM, "Tres Seaver" <tseaver(a)palladion.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/14/2014 09:15 PM, Donald Stufft wrote: > > On Oct 14, 2014, at 8:50 PM, Stefan Krah <stefankrah(a)freenet.de> > > wrote: > > > >>> Donald Stufft <donald <at> stufft.io> writes: > >>> > >>>>> If you're this upset over someone redistributing your work, > >>>>> then maybe Open Source Software is the wrong hobby for you. > >>> > >>> Usually one does not tell a core developer that his contributions > >>> are "a hobby". I have contributed 40000+ lines of original, dense > >>> C code, backed by 100% code coverage and 30000+ lines of ACL2 > >>> proofs. > > Uhh, maybe you’re misunderstanding the word hobby, unless you’re > > getting paid for your OSS work you’re not doing it professionally. A > > hobby isn’t a negative thing, until last December my OSS work was > > entirely a hobby too, and it’s still a hobby in my spare time too. > > That use of "hobby" vs. "professional" is completely irrelevant to the > discussion, and is effectively condescending and ad hominem. In my > experience, the quality and committment of a developer's open source work > are often unrelated to whether she gets paid directly by an employer to > do it. Getting paid *does* make it possible to devote more time, rather > than passion, to one's projects. > > > > Tres. > - -- > =================================================================== > Tres Seaver +1 540-429-0999 tseaver(a)palladion.com > Palladion Software "Excellence by Design" http://palladion.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAlRAPOIACgkQ+gerLs4ltQ5vWACfRDCmT5yjkqfeBB+4xGAiBnAv > n7MAoKag+7GkicRdZ9eSpJdz+HKml6aG > =5Uxr > -----END PGP SIGNATURE----- > A hobby is by definition what you do in your free time. Donald is clearly encouraging Stefan to spend his free time as he wishes. None of us who participate in our free time are obligated to support anything beyond our desire to do so, unlike someone who's paid to work on their project(s). It almost seems like you're nitpicking the valid usage of a word to pile into an argument in which you have nothing valid to say. I know it doesn't usually happen on mailing lists, but that's what it seems like here.

2 1

Process for taking over abandoned packages
by Tennessee Leeuwenburg 17 Oct '14

17 Oct '14

Hi all, I have just finished reading through most of the prior discussion on this issue, but as I read it in one sitting, I can't promise to have covered every nuance. I would like to propose that the pendulum has swung too far for some use cases. The use cases covered in that discussion appeared to me to be (a) Process for not allowing takeover a not-really/not-fully abandoned project (b) Process for taking over a (really) abandoned but useful project (c) Establishing graceful handover request processes and matchmaking I would like to suggest another edge case: (d) Taking over an abandoned project which does not have any code, hasn't been touched for years and doesn't do anything. That is to say, squatting. The projects which fill some use provide value to people because regardless of what maintainer politics may be happening, they are still installable, useful things. Squatter packages don't do any good to anyone. Mostly, these will have been created with good intentions to "get round to it" or otherwise provide some value to the community. However for whatever reason, they get left behind. If the original creator is still on email, then this can be handled through normal process and the wishes of the original author can be identified. However, I am in the middle of a situation where that's not the case, and the current formalities don't allow any wriggle room (as written, anyway). One possibility would be to allow take-over in non-contactable situations where the utility of the namespace is being wasted (subject to the administrator's interpretation). Another would be to use the "Development Status" flag to put different controls in place. Regardless, I am currently in a situation where I would like to register a particular name, and make use of it for at least somewhat valuable code. Someone registered the same name ages ago (over a year) and there's no code in it, and the github repo for the project is similarly inactive. They can't be reached. I've just posted to the issue tracker in case that reaches them, but my hopes are not high. I think it's a shame if the policy is written such that there is no recourse for exceptions and no way to avoid "locking in" cruft and accumulation of bad packages with no clear future use. I think it's also a reasonable requirement that maintainers and authors be contactable (within some definition of time period etc) In this case, I can consider another name, of course. Unfortunately (for me), this whole policy discussion has only come up after I started the process of looking into a pypi name takeover. I've put energy into setting up the project with its current name, and have now put a fair bit of time into trying to meet everyone's needs with regards to the PyPI entry. Changing the pypi name means changing all kinds of other information systems in order to have naming consistency, it's not just a trivial matter for me. It's hard for me to see how anyone is benefiting from this situation -- the current nameholder isn't actually doing anything, and it's just putting the brakes on getting things done and wasting namespace. I'd appreciate it if this group could consider putting some wording around handling exceptional circumstances, and/or dealing with "squatter" type scenarios. I realise I have simplified a few things, but I did so in the interest of getting to what I thought the most important aspects were. Let me know if you'd like any more information. Regards, -Tennessee -- -------------------------------------------------- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think"

5 8

some questions about PEP470
by holger krekel 16 Oct '14

16 Oct '14

Hi Donald, Nick, to change the somewhat unsuccessfull way how we were conversing about PEP470 so far i'd like to kindly ask you a few questions related to the PEP. This is to check if i am maybe barking up the wrong tree and also to enlarge the common ground/understanding that we are discussing on. Please take your time, i'd appreciate if you give a joint answer rather than a quick one. thanks, holger Numbers of users affected --------------------------------- Do i see it right that the PEP470 changes would mean about 6-7 thousand users (per day) need to change their installation options to use "--extra-index-url"? If not, how many? Is there a monthly figure? And that the affected users can only do that if the respective maintainers of the projects offer an external index (or re-upload to PyPI)? Do i see it right that up to a 1000 maintainers need to act and offer an external index if they want to keep their projects properly installable? What can users of (older or current) easy_install versions do if they want to install a project with external links in a post PEP470 world? How many people currently use easy_install/not-pip (numbers, not only percentages)? I've understood you made these two statements during the discussion: - PEP438 caused bad UI for dealing with pypi-external links -- many people are confused by it and we thus need to fix it. - PEP470 breaking backward compatibility for pypi-external links is not a big deal because it affects only a tiny fraction of the users. Could you choose which one of them you consider is true? Recommendation of "--extra-index-url" -------------------------------------- In your mind and forgetting about PEP470, in what situations exactly is "pip install --extra-index-url" a safe option for users? Interpretation of external link usage -------------------------------------------- In the main rationale you say: "While a large number of projects did ultimately decide to upload to PyPI, some of them did so only because the UX around what PEP 438 was so bad that they felt forced to do so." Could you provide some tractable background (not just your strong opinion) for this interpretation? Why can it not be that people nowadays just prefer to upload to PyPI without even considering alternative options?

8 26