<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 February 2017 at 23:04, Freddy Rietdijk <span dir="ltr"><<a href="mailto:freddyrietdijk@fridh.nl" target="_blank">freddyrietdijk@fridh.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><span style="font-size:12.8px">> Here's an example I've just run into that involves a == dependency on</span><br style="font-size:12.8px"><span style="font-size:12.8px">a public package: I have a library that needs to access some C API</span><br style="font-size:12.8px"><span style="font-size:12.8px">calls on Windows, but not on other platforms. The natural way to do</span><br style="font-size:12.8px"><span style="font-size:12.8px">this is to split out the CFFI code into its own package,</span><br style="font-size:12.8px"><span style="font-size:12.8px">_mylib_windows_helper or whatever, that has zero public interface, and</span><br style="font-size:12.8px"><span style="font-size:12.8px">have mylib v1.2.3 require "_mylib_windows_helper==1.2.3; os_name ==</span><br style="font-size:12.8px"><span style="font-size:12.8px">'nt'". </span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">You have a public library, that, depending on the platform, depends on a public (helper) library that has no public interface? That doesn't sound good to me. If you don't want to implement a public interface then it should just be included in the main library because it is in the end a requirement of the library. It's a pity you can't have a universal wheel but so be it. Choosing to depend on an exact version of a package that has no public interfance is in my opinion the wrong solution.<br></span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">As I stated before, though perhaps not explicitly, I cannot think of *any* good reason that one uses == in `install_requires`. Something like `>= 1.7, < 1.8` should be sufficient. In the CFFI case that should be sufficient unless you change your function signatures in a maintenance release (which is bad). And in case of a metapackage like </span><span style="font-size:12.8px">PyObjC this should also be sufficient because it will downgrade dependencies when downgrading the metapackage while still giving you the latest maintenance releases of the dependencies.</span></div></div><div><br></div><div><span style="font-size:12.8px">Regarding 'application', 'library', and 'metapackage'. In Nixpkgs we distinguish Python libraries and applications. Applications are available for 1 version of the interpreter, whereas libraries are available for all (supported) interpreter versions. It's nice if it were more explicit on say PyPI whether a package is a library or an application. There are difficult cases though, e.g., `ipython`. Is that an application or a library? As user I would argue that it is an application, however, it should be available for each version of the interpreter and that's why we branded it a library.</span></div></div></blockquote><div><br></div><div>That sounds pretty similar to the distinction in Fedora as well, which has been highlighted by the Python 3 migration effort: libraries emit both Python 2 & 3 RPMs from their source RPM (and will for as long as Fedora and the library both support Python 2), while applications just switch from depending on Python 2 to depending on Python 3 instead.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px"></span></div><div><span style="font-size:12.8px">Metapackages. `jupyter` is a metapackage. We had to put it with the rest of the Python libraries for the same reason as we put `ipython` there. From a</span><span style="font-size:12.8px"> distributions' point of view I don't see why you would want to have them mentioned separately. </span></div></div></blockquote><div><br></div><div>From a distro point of view, explicit upstream metapackages would provide a hint saying "these projects should be upgraded as a unit rather than independently". We're free to ignore that hint if we want to, but doing so means we get to keep the pieces if they break rather than just being able to report the problem back upstream :) <br></div><br></div><div class="gmail_quote">Cheers,<br></div><div class="gmail_quote">Nick.<br></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>