pmxbot IRC Log Viewer

[07:26:00] <wiggy> morning

[11:49:05] <doismellburning> if I wanted `setup.py` to read `requirements.txt` for `install_requires`, is there a recommended least-awful way to do so?

[11:49:17] <doismellburning> I am aware this is generally a bad plan, but, alas, Constraints

[11:52:22] <doismellburning> !logs

[11:52:22] <pmxbot> http://chat-logs.dcpython.org/channel/pypa

[11:53:45] <ionelmc> doismellburning: https://github.com/audreyr/cookiecutter-pypackage/pull/61

[11:53:54] <doismellburning> ionelmc: amazeballs, thanks

[11:54:09] <ionelmc> then again

[11:54:28] <ionelmc> if you put concrete reqs in install_requires then you're looking for trouble

[11:54:32] <doismellburning> We have a build system that _requires_ services to be packaged as libraries

[11:54:56] <doismellburning> Fixing that is planned, but not in the short term

[11:55:32] <ionelmc> heheh

[11:55:35] <doismellburning> yeah

[11:55:46] <ionelmc> that means you're using data_files

[11:55:55] <ionelmc> i feel sorry for you :)))

[11:58:10] <doismellburning> eh?

[11:58:11] <doismellburning> we're not

[12:24:11] <nedbat> ionelmc: what do you mean by "if you put concrete reqs in install_requires" ?

[12:28:47] <Ivo> doismellburning: here is what you want to know

[12:28:48] <Ivo> https://caremad.io/2013/07/setup-vs-requirement/

[12:30:05] <doismellburning> Ivo: er, I'm not sure it is, but thanks

[12:30:34] <doismellburning> (can't see any mention of `data_files` / how to do what I was asking)

[12:30:39] <Ivo> doismellburning: it largely explains why that's usually a bad idea

[12:30:59] <Ivo> sorry, in relation to your frst question

[12:31:00] <doismellburning> Ivo: right, but I already know that

[12:31:07] <doismellburning> Ivo: hence "fixing that is planned"

[12:31:17] <doismellburning> and "I am aware this is generally a bad plan"

[12:32:27] <Ivo> how does requiring things to be libraries mandate that course of action doismellburning?

[12:33:54] <doismellburning> Ivo: because pip (entirely reasonably) uses `setup.py`'s `install_requires`

[12:34:23] <Ivo> go on

[12:34:35] <doismellburning> ...?

[12:35:32] <Ivo> but why must you programmatically grab what happens to be in requirements.txt and put in the install_requires array?

[12:35:52] <doismellburning> "must" is somewhat strong

[12:36:17] <Ivo> ok, so if it's not must, I would advocate against it

[12:36:37] <doismellburning> but the main use-case is that requires.io only accepts the various commented directives in `requirements.txt` and not in `setup.py` (entirely reasonably)

[12:37:26] <doismellburning> and having a tonne of breaking PRs trying to update some of these services to Django 1.8 from 1.7 is proving tedious

[12:39:28] <Ivo> you're trying to update a project from 1.7 to 1.8?

[12:40:22] <doismellburning> ...no

[12:40:34] <doismellburning> I have no intention of updating the project to 1.8 in the short-term future

[12:43:55] <jessamynsmith> doismellburning: I have an app stuck on 1.7 -- I need at some point to figure out why my attempt at 1.8 upgrade failed

[12:46:53] <doismellburning> jessamynsmith: heh I think we know in most cases fortunately, just a question of prioritisation

[12:48:51] <ionelmc> nedbat: did you read https://caremad.io/2013/07/setup-vs-requirement/ ?

[12:51:25] <Ivo> doismellburning: a tonne of people are erroneously trying to require django 1.8 in your project with their PRs?

[12:53:15] <doismellburning> Ivo: no, requires.io is

[12:56:03] <Ivo> doismellburning: so you could put django~=1.7.2 insteasd of just django

[12:56:32] <Ivo> (the 2 is arbitrary)

[12:56:59] <doismellburning> I mean, we have a policy of explicitly pinning versions for services

[12:57:08] <doismellburning> nobody likes surprise version changes

[12:57:24] <doismellburning> but maybe we could; I'd still rather just do what I talked about above

[12:58:01] <jessamynsmith> doismellburning: the pinning convention is something I like about python

[12:58:22] <jessamynsmith> the lack of pinning in most js libs causes no end of trouble, in my experience :/

[12:58:28] <doismellburning> jessamynsmith: ...I should finish my lockfiles post ;)

[12:58:33] <doismellburning> jessamynsmith: tl;dr play with Ruby's bundler and co

[12:58:37] <jessamynsmith> ah

[12:58:45] <jessamynsmith> I have helped people a little, but I don't do ruby

[12:58:46] <ronny> pinning should be in separate files :)

[12:58:49] <doismellburning> jessamynsmith: you'll like the pinning convention less ;)

[12:58:53] <doismellburning> ronny: agreed

[12:59:05] <ronny> i.e. setup.py leaves it flexible, project requirements.txt sets it up very exact

[12:59:08] <jessamynsmith> I just mean I like having a convention where you don't just wave your hands and hope it works

[12:59:12] <doismellburning> jessamynsmith: absolutely

[12:59:15] <ronny> does js have something comparable?

[12:59:26] <jessamynsmith> package.json in node

[12:59:32] <doismellburning> jessamynsmith: without lockfiles though, that _is_ still what happens in many cases

[12:59:32] <jessamynsmith> but you'll like it even less than what python does

[12:59:47] <jessamynsmith> plus most people don't specify exact versions

[13:00:32] <jessamynsmith> now that I've totally distracted myself with this convo... I actually came in here because I was wondering about pip updating of all files in a virtualenv

[13:00:47] <jessamynsmith> I *thought* I had discovered a way in new pip to upgrade all

[13:00:51] <jessamynsmith> but now I can't remember

[13:39:27] <vila> dstufft: floowing you from #bzr ;) I tried to upload the latest tarball and ended up with Error processing form

[13:39:27] <vila> Invalid version, cannot be parsed as a valid PEP 440 version.

[13:39:40] <dstufft> vila: what's the version number?

[13:40:14] <dstufft> isn't it just 2.6.0?

[13:40:40] <vila> dstufft: 2.6.0 but I don't know where you look for it, internally it may be 2.6.0final0 or something

[13:40:57] <dstufft> vila: is the tarball available publically somewhere I can look at it?

[13:41:28] <vila> dstufft: https://launchpad.net/bzr/2.6/2.6.0

[13:42:50] <barry> dstufft: i tried uploading launchpadlib-1.10.3.tar.gz but it said the filename was already taken

[13:43:00] <dstufft> heh

[13:43:03] <dstufft> oh goody

[13:43:09] <dstufft> so

[13:43:31] <dstufft> bzr uses only distutils, which doesn't bake the "compiled" metadata into a file inside of the .tar.gz

[13:43:38] <dstufft> so twine has no way of reading that information

[13:44:34] <dstufft> So the question then becomes

[13:44:47] <dstufft> how important is it to you that the exact same (as in, the hashes match) tarball gets uploaded

[13:45:02] <dstufft> barry: I can release it, sec

[13:45:30] <vila> dstufft: very. The laternative is to cut a new release which.... can't be done easily (short version)

[13:45:39] <vila> *alternative

[13:46:49] <vila> dstufft: *next* release can take any new constraint into account but for 2.6.0 there is no time machine

[13:47:04] <dstufft> barry: released

[13:47:51] <dstufft> vila: thinking a sec

[13:47:52] <barry> dstufft: looks great, thanks

[13:48:59] <dstufft> vila: good news is, you can do it, the bad news is, it's going to require hacking twine up

[13:49:30] <dstufft> sec

[13:50:09] <dstufft> https://github.com/pypa/twine/blob/master/twine/repository.py#L62

[13:50:21] <dstufft> you're going to want to change that line so it uses a hardcoded dictionary of values from setup.py

[13:50:45] <vila> dstufft: and at some point I will see the file uploaded on pypi ?

[13:51:44] <dstufft> vila: sorry, twine is a utility to upload already existing files to PyPI, however your existing tarball doesn't have the static metadata twine needs to be able to inspect an already created tarball

[13:51:54] <vila> dstufft: yup, got that

[13:52:14] <dstufft> so you need to override the step where twine attempts to read the metadata from the tarball, and replace it with hardcoded values

[13:53:24] <vila> oh, great, testing before uploading, excellent

[13:54:20] <dstufft> twine's gotten refactored since I last looked at it

[13:54:57] <dstufft> you might be able to just use twine as a library, and instatiate your own PackageFile object https://github.com/pypa/twine/blob/master/twine/package.py#L42 with the correcet metadata (instead of using the from_filename classmethod)

[13:55:15] <dstufft> or subclass it and replace the metadata_dictionary

[13:55:36] <dstufft> and then pass that object into Repository().upload() (https://github.com/pypa/twine/blob/master/twine/repository.py#L20)

[13:56:47] <dstufft> Does that all make sense? I have a meeting in 8 minutes, but after that I can try to upload it for you if you give me permissions again (I dropped them after I gave them to you)

[13:56:50] <vila> dstufft: ack, able to make twine upload .tgz .asc fails, now to create the metadata...

[13:57:57] <dstufft> FWIW I suggest switching to setuptools in your setup.py and always using twine to upload (setup.py is.. problematic, it amy or may not use TLS or validate TLS depending on what version of Python you're using)

[13:57:57] <vila> I have version 1.3.1 here

[13:58:10] <dstufft> 1.3.1 is older than the refactor I think

[13:58:35] <dstufft> the refactor made it possible to use twine as a library :/

[13:59:06] <vila> dstufft: well, at that point, I can as well patch the installed version right /

[13:59:07] <vila> ?

[13:59:15] <dstufft> yea

[13:59:19] <dstufft> you can

[13:59:38] <dstufft> it shouldn't be super complicated, you'll want to look in the twine/commands/upload.py file IIRC

[13:59:56] <dstufft> in 1.3.1

[14:00:31] <vila> yeah, I see a big data http://pastebin.ubuntu.com/12554550/ which sounds like my target

[14:01:38] <dstufft> if you run setup.py register first, I *think* i can omit everything but name and version

[14:01:51] <dstufft> oh and filename and py_version

[14:02:02] <dstufft> and :action and protocol_version

[14:02:27] <vila> dstufft: if I fail to provide a required field the upload will fail right ?

[14:02:57] <dstufft> it should yes... but PyPI's codebase is not great. You can try to upload it testpypi.python.org first though if you want

[14:03:09] <dstufft> sorry, by should I mean, I think it will

[14:15:42] <vila> dstufft: sorry, just noticed 'I have a meeting in 8 minutes'. I'm making slow progress and let you know if I succeed. Otherwise, once you're back and still willing to help, I'd be happy to give you permissions ;)

[14:37:59] <dstufft> vila: I'm done now

[14:41:19] <vila> dstufft: my saviour, I'm a bit lost, discovering pkginfo.Distribution() attributes is a bit late in the game :-/

[14:41:33] <vila> dstufft: I did setup.py register

[14:41:59] <dstufft> vila: Ok, just give me permissions

[14:42:36] <vila> in the roles page, user dstufft owner ?

[14:42:50] <dstufft> vila: yea

[14:42:58] <vila> donw

[14:43:02] <vila> done even

[14:45:28] <vila> https://pypi.python.org/pypi/bzr has recovered the old Journal entries it seems

[14:46:32] <vila> best guess is that tanner wanted to remove *himself* as maintainer rather than the project (faith in humanity !)

[14:46:34] <dstufft> deleting doesn't delete journal entries

[14:46:47] <vila> dstufft: that's a Good Thing ;)

[14:54:59] <dstufft> vila: file uploaded, want to check the hash?

[14:56:52] <vila> dstufft: checked, thanks !

[14:57:01] <vila> bac: still there ? Can you test ?

[14:57:06] <dstufft> Ok, gonna drop myself off the package again then

[14:57:13] <bac> vila: sure

[14:57:39] <vila> dstufft: thanks again ! And more thanks from all the users that won't notice...

[14:58:08] <vila> no realrly, can'at TYPRE with fingers cfrossed

[14:58:11] <bac> vila: we specify bzr=2.6.0 but 2.7.0dev1 installed just fine

[14:58:33] <vila> bac: err, wait

[14:58:42] <vila> bac: we uploaded 2.6.0

[14:59:37] <vila> bac: hmm, my bad, I registered from the wrong place

[15:00:14] <vila> bac try again

[15:00:35] <dstufft> 2.6.0 is what I see - https://caremad.io/s/BQsMPM79hb/

[15:01:00] <bac> vila: sorry, my bad. it found 2.7.0 in my system and used it instead. removing that causes it to properly fetch and install 2.6.0

[15:01:59] <vila> bac: ok, I think we're good then

[15:02:08] <bac> vila: yep: Collecting bzr==2.6.0 (from -r test-requirements.pip (line 2))

[15:02:10] <bac> happy

[15:02:21] <vila> pfew, /me feels better

[15:02:39] <vila> dstufft: whenever, I owe you your favorite drink

[15:04:04] <dstufft> vila: no problem!

[15:05:02] <bac> thanks dstufft and vila!

[15:05:11] <bac> and barry

[15:06:48] <barry> cheers!

[15:09:21] <vila> yeah, thanks barry, sorry, that was stressful and I almost forgot that you put the right effort in the right place ;)

[15:10:06] <barry> vila: i try to do as little as possible and take as much credit as given :)

[15:12:18] <vila> barry: great, so, I will say you restored the pypi bzr project and can keep hiding in my basement ;)

[15:13:02] <vila> bac: ^ I did nothing, you don't even remember my nick

[15:14:09] <barry> :)

[19:38:45] <preyalone> Could we please make it easier to list a package's previous versions, and view the details at a given revision?

[19:45:26] <dstufft> preyalone: like on https://warehouse.python.org/project/requests/?

[19:52:47] <tos9> what does platform mean on warehouse

[19:53:39] <dstufft> tos9: it means whatever it means in one of the metadata PEPs. Since it's an old data field, that problably means it's severely underspecified it doesn't really mean much of anything

[19:53:48] <maugzoide> I have a fork of python-etcd and I would like to add this package to my setup.py. It is on Github in a public repo. Giving the branch name install a wrong version. Is this documented? How to install from git inside setup.py?

[19:53:58] <tos9> dstufft: :) fun

[19:54:32] <dstufft> "A comma-separated list of platform specifications, summarizing the operating systems supported by the package. The major supported platforms are listed below, but this list is necessarily incomplete."

[19:54:58] <dstufft> in pratice it's just a free form text field for people to YOLO whatever they want platform to mean

[19:55:14] <dstufft> maugzoide: you don't install from git inside of setup.py

[19:55:32] <dstufft> maugzoide: https://caremad.io/2013/07/setup-vs-requirement/

[19:55:39] <maugzoide> dstufft: ok, this is a good info.

[19:56:05] <maugzoide> Yes, I already do it but I missed this part "you don't install from git inside of setup.py". Thank you!

[21:56:03] <paroneayea> hello!

Log file Viewer

Help | Karma | Search:

#pypa logs for Friday the 25th of September, 2015