pmxbot IRC Log Viewer

[00:35:48] <timous> hi

[00:35:53] <timous> anybody out there?

[00:46:32] <agronholm> timous: ask, don't ask to ask

[00:47:31] <timous> ok, I'm writing a setup.py in which I declare a requirement:

[00:47:54] <timous> install_requires='watchdog==0.8.3'

[00:48:12] <agronholm> install_requires should be a list or tuple

[00:48:46] <timous> yes, the actual line is install_requires=['watchdog==0.8.3']

[00:48:52] <agronholm> go on

[00:48:58] <timous> upload to pypi succesful

[00:49:22] <timous> pip install -i https://testpypi.python.org/pypi mymodule

[00:49:29] <timous> starts normally

[00:49:47] <timous> until: 'Could not find a version that satisfies the requirement watchdog==0.8.3 (from..'

[00:50:09] <timous> when I 'pip install watchdog==0.8.3' locally it works

[00:50:12] <timous> why ?

[00:50:44] <agronholm> timous: what's the name of your package on testpypi?

[00:50:50] <agronholm> it's not actually "mymodule" is it

[00:50:50] <timous> giterm

[00:50:53] <agronholm> ok

[00:53:02] <agronholm> timous: unrelated question: why do you have your requirements in a text file and not in setup.py?

[00:54:03] <timous> I'd prefer since we're used to run 'pip install -r requirements.txt' without going through packaging

[00:54:18] <agronholm> what's the advantage of that?

[00:55:00] <timous> no idea, I'm discovering bad habbits everyday, and this is my very first day with a setup.py in my python project :)

[00:55:12] <agronholm> my advice: ditch the requirements.txt :)

[00:55:22] <agronholm> but

[00:55:29] <agronholm> I haven't figured out why the install fails

[00:55:38] <agronholm> if I download your tarball and pip install it, everything works fine

[00:55:44] <agronholm> so your setup.py is not at fault

[00:55:54] <timous> and now I learnt a new word: 'ditch' :)

[00:56:28] <timous> omg you're saying it works for others, not for me. It's the opposite usually

[00:56:44] <agronholm> it fails the same way for me if I install directly from testpypi

[00:56:53] <agronholm> but if I download the tarball and pip install that, it works

[00:56:55] <agronholm> which makes no sense

[00:57:06] <timous> ok I see

[00:57:25] <agronholm> one more, unrelated thing: always upload a wheel too along with the tarball

[00:57:37] <timous> if it makes no sense to you... i can't help

[00:57:38] <agronholm> and use twine for uploading

[00:57:54] <timous> ok, twine for secure connection, I read that

[00:58:04] <agronholm> move the deps to setup.py and try again

[00:58:09] <agronholm> well, dependency

[00:58:12] <timous> wheel, I don't know what is it yet

[00:58:24] <agronholm> have you read http://packaging.python.org/ ?

[00:58:46] <timous> I wrote it plain text in the setup.py but no more succesful

[00:59:03] <timous> I'm always reading it, it never ends :)

[00:59:13] <agronholm> it should have explained what wheels are

[00:59:20] <agronholm> and how to make them

[00:59:35] <agronholm> is this giterm an application or a library?

[00:59:46] <timous> an app

[00:59:50] <agronholm> ok

[01:00:01] <agronholm> if it were I library I would strongly suggest not pinning it to a specific version

[01:00:07] <agronholm> s/I/a/

[01:00:19] <timous> oh, ok

[01:00:30] <timous> why is that?

[01:00:46] <agronholm> well it's very inconvenient when you need bug fixes or new features

[01:00:56] <agronholm> that version pinning prevents upgrades

[01:01:22] <timous> oh, you mean deps version ?

[01:01:25] <agronholm> yes

[01:01:28] <agronholm> that setup.cfg of yours -- do you use subversion?

[01:01:29] <timous> ah ok

[01:01:37] <timous> git

[01:01:46] <timous> I have no setup.cfg

[01:01:52] <agronholm> what's that egg_info section for?

[01:01:57] <agronholm> I've never seen anything like that

[01:02:15] <timous> don't know what you're talking about

[01:02:28] <agronholm> you have a setup.cfg containing just one section, [egg_info]

[01:02:34] <timous> just run "python setup.py register"

[01:02:41] <agronholm> no but in your tarball

[01:02:47] <timous> then "python setup.py sdist upload"

[01:03:36] <agronholm> timous: are you saying you don't see a setup.cfg in your project directory?

[01:03:41] <timous> sorry to insist, but I don't see what you mean, I never created such files

[01:03:47] <timous> yes, I don't see them

[01:04:16] <timous> I didn't create a setup.cfg

[01:04:17] <agronholm> timous: download your own tarball from testpypi and extract it

[01:04:21] <timous> ok

[01:05:09] <timous> I can see .cfg

[01:05:23] <agronholm> and the tarball you uploaded contains no such file?

[01:05:35] <timous> yes, no such config.cfg

[01:05:40] <agronholm> mysterious

[01:05:49] <agronholm> well, no point in worrying about that

[01:06:07] <timous> lol so many mysteries tonight

[01:06:07] <agronholm> timous: what if you upload a wheel to testpypi?

[01:06:36] <timous> I don't know what you mean, not read that yet :)

[01:07:41] <agronholm> python setup.py bdist_wheel

[01:09:16] <timous> thks, was RTFM :)

[01:10:03] <timous> still 'python setup.py sdist upload ' for upload?

[01:10:19] <agronholm> sdist creates and uploads an sdist, not a wheel

[01:10:30] <agronholm> "python setup.py bdist_wheel upload" creates and uploads a wheel

[01:11:08] <timous> done

[01:12:06] <timous> still same issue about watchdog

[01:12:11] <agronholm> yeah I'm seeing it too

[01:12:31] <agronholm> hrm

[01:12:35] <agronholm> right

[01:12:40] <agronholm> I know what the problem is now

[01:12:40] <timous> I omitted to say I'm running under virtualenv

[01:12:51] <agronholm> it's not searching pypi for watchdog

[01:12:55] <timous> what does hrm mean?

[01:13:37] <timous> ok, straight to the main concern

[01:13:40] <agronholm> synonym to "hmm"

[01:13:53] <agronholm> pip install --extra-index-url https://testpypi.python.org/pypi giterm

[01:13:56] <timous> no idea what hmm means :)

[01:14:11] <agronholm> it's a sound you make when you're deep in thought

[01:14:25] <timous> oh, yes sorry

[01:14:35] <timous> thought it was an acronym :D

[01:14:36] <agronholm> but that command will install giterm

[01:14:41] <timous> i'm a bit tired

[01:14:50] <timous> I'm trying

[01:15:19] <timous> omg <3

[01:16:00] <timous> is it normal/usual to need this option to install a package properly?

[01:16:14] <agronholm> if you use the test pypi instead of the real one

[01:16:27] <timous> what is the difference

[01:16:41] <agronholm> testpypi is for testing if your distribution is accepted

[01:16:46] <agronholm> to debug upload problems

[01:17:01] <agronholm> upload to the real pypi when you need to publish stuff

[01:17:25] <timous> no, I mean why this option is required with testpypi and not with pypi

[01:17:34] <agronholm> because it's not the default package index

[01:17:47] <agronholm> it's to tell pip to look elsewhere for installable stuff

[01:17:55] <timous> oh!!! yes, you mean I cant find watchdog on testpypi

[01:17:58] <timous> of course

[01:18:08] <agronholm> -i switches the main package index

[01:18:23] <agronholm> --extra-index-url adds an auxiliary package index to look for stuff in

[01:18:56] <timous> I'm so happy

[01:19:07] <agronholm> :)

[01:19:08] <timous> many thanks for all the tips

[01:20:00] <timous> it's 2 am here, I think I gonna sleep before doing anything else

[01:20:28] <agronholm> 3:15 here

[01:20:34] <agronholm> good night!

[01:20:59] <timous> thansk! see you!

[01:21:13] <timous> s/sk/ks

[17:18:30] <mcepl> trying to understand how do setup.py subcommands with setuptools get command line arguments (trying to fix https://gitlab.com/m2crypto/m2crypto/issues/89 and I don't how to collect arguments from build command and pass it to build_ext). Any HOWTOs, examples?

[18:17:49] <ionelmc> mcepl: is it possible that the reported had a dirty working dir (that created the problem)?

[18:17:58] <ionelmc> some things are cached

[18:18:51] <ionelmc> it's always prudent to `rm -rf build *.egg-info`

[20:03:33] <mcepl> ionelmc: no, that isn't the point ... I have --openssl option for build_ext, but I would like to have it even for build (which would pass it to build_ext subcommand).

[21:05:44] <ronny> mcepl: i vaugely recall its enough to add it to the build command a s option as well, the build_ext command takes options from the build command in the normal chain

[21:19:20] <mcepl> ronny: interesting

[21:22:11] <ronny> mcepl: it should works just as the compile flag to build that will pass trough to build_py

[22:09:03] <mcepl> ronny: hmm, I have this setup.py http://paste.fedoraproject.org/303315/14505625/ and the result is not good http://paste.fedoraproject.org/303316/62586145/

[22:11:15] <ronny> mcepl: off hand no idea - i havent worked with the code in question since a while

[22:11:34] <mcepl> oh well, thanks anyway

[22:20:29] <timous> agronholm: hi

[22:21:30] <timous> yesterday you told me "ditch the requirements.txt", how do I do that? should I use the setup.py instead?

[22:22:03] <agronholm> timous: yes

[22:22:17] <agronholm> timous: so do what everyone else does :)

[22:23:50] <timous> so, when I start a dev env, the procedure is 1. mkvirtualenv 2. python setup.py and that's it?

[22:32:39] <Wooble> timous: "pip install ." is better than running setup.py directly (possibly with -e switch if you're developing the module...)

[22:33:15] <timous> Ho! wow, didn't know that!

[22:35:20] <Wooble> (for one thing, if your setup creates scripts with entry_points, you can pip uninstall them if you use pip to install; if you use setup.py develop you can't)

[22:38:03] <timous> great to know!

[22:38:22] <timous> it does indeed

[22:39:02] <tos9> Also, setup.py and requirements.txt are different things, so no you wouldn't replace one with the other.

[22:39:11] <tos9> https://caremad.io/2013/07/setup-vs-requirement/

[22:40:10] <timous> so what about setup.py files that read in requirements.txt? :D

[22:40:30] <timous> definitely loks like a bad idea in the end

[22:40:32] <tos9> Those would be the sorts of things to make people using your library pretty angry :P

[22:40:49] <tos9> Occasionally the reverse is what you want though. See the article I linked.

[22:41:00] <timous> Well, let me fix that quickly :)

[22:41:09] <timous> I'm reading ;)

[22:42:40] <Wooble> huh? How does a requirements.txt read setup.py? :/

[22:43:10] <timous> lol, like this:

[22:43:13] <timous> with open("requirements.txt") as f:

[22:43:13] <timous> required_packages = [l for l in f.read().splitlines() if not l.startswith("#")]

[22:43:20] <timous> ...

[22:43:21] <timous> install_requires=required_packages,

[22:43:50] <Wooble> that's... not the opposite.

[22:44:01] <tos9> Yeah that's completely wrong :)

[22:44:12] <tos9> The reverse is e.g. putting `-e .` in the requirements file.

[22:44:24] <Wooble> ah.

[22:45:07] <Wooble> does that go horribly wrong if your working directory isn't the project when you install?

[22:45:20] <tos9> pip always cd's.

[22:45:44] <tos9> (The world is a terrible place.)

[22:46:04] <timous> since you're given the path to pip, I guess

[23:10:55] <timous> tos9: read the article, I don't get it all

[23:12:08] <timous> start with a requirements.txt with concrete deps, and ends with just "-e ." where the versions go?

[23:13:34] <timous> given example are a bit too abstract

[23:13:51] <timous> in my case I have "watchdog==0.8.3"

[23:14:00] <timous> what should I write instead?

[23:14:18] <timous> since it's an app, not a lib

[23:20:48] <tos9> that goes in requirements.txt

[23:20:56] <tos9> your setup.py might instead say "watchdog"

[23:27:48] <timous> but it's an app, it should run even in the future

[23:28:42] <timous> let's say myapp does not change, but watchdog does and breaks myapp support of watchog, that's no good right?

[23:29:10] <timous> for a lib it's different since I should maintain to get always up to date with dependencies

[23:29:41] <timous> but for an application? it should be always reproductible

[23:30:14] <timous> reproducible

[23:30:38] <tos9> That's what a requirements.txt *is* :)

[23:30:46] <tos9> It's the known set of working versions for your deployment of your application.

[23:30:54] <timous> hum

[23:31:20] <timous> the window is opening slightly

[23:31:29] <tdsmith> if the app is published on pypi and `pip install my-great-app` doesn't work that's balls thopugh

[23:31:56] <timous> yeah! that's what I mean

[23:32:49] <tdsmith> all options are bad

[23:33:07] <tdsmith> the ~= operator helps a little; see https://www.python.org/dev/peps/pep-0440/#compatible-release

[23:33:44] <tdsmith> if you depend on e.g. requests and requests gets updated to fix security vulnerabilities but remains api-compatible, apps with aggressive pins are annoying to work around

[23:34:45] <timous> yes, but we depend on the fact that request must ensure not breaking API compatibility accros minor revisions

[23:35:04] <timous> (semantic versioning) but we have no warranty for that

[23:36:06] <timous> (thanks for the ~= operator, btw)

Log file Viewer

Help | Karma | Search:

#pypa logs for Saturday the 19th of December, 2015