Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    David Brochart
    @davidbrochart
    no, first because they have __
    and even without __, glibc doesn't exist as a package
    David Brochart
    @davidbrochart
    if we add the virtual packages to the installed packages, and another version is needed, it will try and get that version.
    Wolf Vollprecht
    @wolfv
    but it should fail if it's not available, right? Or rather it should print something like: Your system is out of date, could not find a variant for QT that was built for OS X == 10.8
    no it should fail, right? because there is no __osx package in conda-forge or elsewhere
    David Brochart
    @davidbrochart
    yes
    oh you're right
    it's that simple!
    Wolf Vollprecht
    @wolfv
    :)
    David Brochart
    @davidbrochart
    but the package has to request __osx, not osx
    is it the rule?
    Wolf Vollprecht
    @wolfv
    they have __osx in the constrains field
    let me sent you an example
    David Brochart
    @davidbrochart
    ok, I thought they had osx
    Wolf Vollprecht
    @wolfv
        "code-server-2.1698_vsc1.41.1-h4a8c4bd_0.tar.bz2": {
          "build": "h4a8c4bd_0",
          "build_number": 0,
          "constrains": [
            "__osx >=10.9"
          ],
          "depends": [
            "icu",
            "libcxx >=9.0.1",
    ...
    this constrains is a run constraint ... it basically says: don't try to install the package, but the package cannot work with another version
    David Brochart
    @davidbrochart
    ok, that works then
    thanks!
    Wolf Vollprecht
    @wolfv
    :tada:
    Sylvain Corlay
    @SylvainCorlay
    @mariobuikhuizen you saw the email of the jupyterlab-snippets guy :)
    We an use the name
    only issue is that we need to start the version with 0.3.0. Because we cannot reuse an existing combination of name / version on PyPI.
    David Brochart
    @davidbrochart
    @wolfv one annoying thing with QuantStack/mamba#87 is that you will see explicitly e.g. Looking for: ['rasterio', 'python 3.7.6'] and python again in the added specs, even though you didn't specify it... conda was doing it implicitly, and with mamba we do it explicitly. I know sometimes explicit is better than implicit, but I'm not sure if we should hide it.
    Sylvain Corlay
    @SylvainCorlay
    @JohanMabille so it seems indeed that the xeus-statictarget may need to export pthreads in its interface.
    Given the build failure here: jupyter-xeus/xeus-python#235.
    Wolf Vollprecht
    @wolfv
    yeah agreed @davidbrochart this message was mostly there for debugging purposes anyways
    we should think what we want to show to the user
    I think this might be a message that we can get rid of entirely (or hide it behind one of the verbosity levels)
    Johan Mabille
    @JohanMabille
    @SylvainCorlay ok I will make a PR tonight
    Sylvain Corlay
    @SylvainCorlay
    @JohanMabille I am looking at whether there is a good practice for that.
    Why is it required for the static build and not the dynamic build?
    Johan Mabille
    @JohanMabille
    I guess that you won't accept "because the compiler complains about it missing" as an answer?
    more seriously I don't know
    I guess that we don't link with the same runtime in static and in shared mode
    and maybe one brings in the thread library?
    Sylvain Corlay
    @SylvainCorlay
    Maybe @serge-sans-paille knows that kind of stuff.
    @martinRenou did you push something on the inline backend?
    serge-sans-paille
    @serge-sans-paille
    @SylvainCorlay: what's the context?
    Sylvain Corlay
    @SylvainCorlay
    basically, we have this library (xeus)
    we build a static and a shared version of xeus.
    projects linking with xeus-static (libxeus.a) apparently also need to link with Threads while those linking with xeus (libxeus.so) don't.
    So we are looking at making a call to
    target_link_libraries(xeus-static PUBLIC Threads::Threads)
    So that it is automatic - but I don't know the reason why this is needed, and why this is needed in one case and not the other.
    serge-sans-paille
    @serge-sans-paille
    well, a static library is just an archive containing a bunch of .o files, so the notion of dependencies doesn't actually make sense (at the ELF level)
    and yeah, cmake (or pkg-config, or...) make it possible to describe these dependencies externally
    @SylvainCorlay not sure that was your question though
    Sylvain Corlay
    @SylvainCorlay
    I am not quite sure why the .so makes it so that clients of the library don't need to link with pthreads, while the .a does not.
    serge-sans-paille
    @serge-sans-paille
    maybe the client is only using symbols that don't reference pthread?
    Said otherwise, when you link with a .a, you only pull the .o that contain symbols you need. If among these .o, there's no refrence to pthread, you don't need pthread