Mark appnope as an unsafe package

[achauve]

or provide a way to configure unsafe packages via cli option on config file.

Ipython requires appnope on OSX only, so generated requirements.txt. fails on linux afterwards.

see PR #278

[khwilson]

ipython's reliance on appnope is annoying for this toolchain. If it's any help, we get around this with a bit of sed in our tox.ini, which solves the problem "well enough" for our purposes:

[testenv:pip-compile]
deps=
    pip-tools==1.2.0
whitelist_externals=
    sed
    rm

; iPython 4 has a darwin only platform dependency on appnope. pip-compile is not platform aware and
; outputs this unconditionally. We use sed to patch in the dependency until pip-compile is
; platform aware.
commands=
    pip-compile requirements.in -v
    sed -i.bak -e's/^appnope[^[:space:]]*/&;sys_platform=="darwin"/' requirements.txt
    rm requirements.txt.bak

[nvie]

Agreed, this is annoying. I don't think we can guarantee desired behaviour here under all circumstances. In a way, pip-tools has to work with the output of pip, which on a single machine, is quite platform-specific. However, I would support a command line flag like --ignore appnope or something like that if that would practically solve this issue. If you want to make a PR for this, I'm happy to pull it.

[khwilson]

tbh, I'm really not sure you should be trying to get around it because who knows how deep the rabbit hole goes. But maybe an --ignore-platform-specific flag (or perhaps something with a better name)? Maybe pip-compile would go ahead and resolve the dependencies for the local platform and then comment them out in the resulting requirements file, or would just leave them tagged with ;sys_platform=sys.platform? I think either of those options would be better than an outright --ignore.

Thoughts?

[nvie]

How would you detect those without residing to parsing the package's metadata yourself? Right now, I'm basically letting pip do all the heavy lifting by simply asking it what the dependencies are. Not sure if we can detect from there is certain deps are platform specific.

[khwilson]

The appnope dependency arises from an extras_require[':sys_platform == "darwin"] = ['appnope'] type situation. So there are choices you could make, e.g., monkey patching sys.platform or, perhaps better, changing the PEP-0425 tags passed to pip. (I haven't looked at the pip source in a while, but I'm pretty sure there's an option for this.)

As for labeling them in requirements.txt, in the worst case scenario, you could do dependency resolution twice, once with the above scheme and once in the regular way and take a set difference. Though there might be a simpler way to do this depending on how pip keeps track internally of its markers.

[nvie]

Monkey patching sys.platform is likely going to pose issues around command invocation on Windows (pip-tools uses subprocess, which likely uses sys.platform to dispatch OS specific behaviour). As far as the other options we have, I'm unsure about. I agree it'd be nice to automatically exclude/ignore the platform-specific packages, and to add a command line flag to not do that by default. In that case, it may be good to still write the requirement into the requirements.txt file, but to comment it out. (So the user won't be surprised the package is not in there.)

If you have time to prepare a PR for this, I'm happy to pull.

[jbg]

We’d like to work around this issue by listing ipython in requirements.in like this:

ipython; sys_platform == 'darwin'

… since we only use it in development and we all use Macs, and then having pip-compile carry the environment marker through to requirements.txt for ipython and any packages that are below it and nothing else in the dependency tree.

I guess that would depend on #206

[barrywhart]

There is now a PR for #206: #459

[vphilippon]

Environment markers from requirements.in are now preserved, giving a solution to deal with environment specific dependencies. Given that and that appnope is not an unsafe dependency, I'll close this.

[tonyseek]

It seems the problem of appnope is not fixed by #460 actually. There is an issue #563 which is discussing about this.