RayDonnelly

I don't understand the nature of your discourse. You agreed that maintaining software distros is not easy, some recommended conda and you seem dismissive again?

Printing them out quickly?

We are a rolling Software Distribution and providing up to date software is one of our main goals.

Another is building that software with good security flags, see: https://www.anaconda.com/blog/developer-blog/improved-securi...

We also keep track of CVEs in our software and actively look for patches (e.g. pycrypto is dead now but Debian maintains patches to fix reported CVEs) or write our own (though usually to fix build-system bugs rather than security issues).

But yes, static linking and leaving software building to non-experts using whatever tools they like (without studying anything to do with low-level binary security or how to achieve that), statically linking insecure (some time to become old) libraries is far from ideal.

Anaconda Distribution strongly prefers dynamic linking and shared package dependencies so we can update to address critical security issues without needing to rebuild significant portions of our stack.

It solves this already and has done for many years (but this depends on what you mean exactly by "the way that Nix does").

If this supported non-PIE I'd try to use it on Anaconda Distribution in a flash.

cold functions are also optimised at -Os.

And what is to stop someone from pushing malicious code to GitHub and you guys distributing malicious packages to end-users via your 'stable' channel?

And who's liable here?

> I'm not really familiar with the latest trends in (bloatware?) development, but a simple game like that taking >100MB would make me suspicious

This is very much the idea of these awful (IMHO) ways of distributing software. Bundle all of your dependencies, share nothing, expose users to the risks of exploits in the libraries you've bundled (and maybe statically so no one can even figure out you have done that).

Please stop this madness.

Glad to hear it. We take these matters very seriously, including good hardening flags etc: https://www.anaconda.com/blog/developer-blog/improved-securi...

Did you miss that I was replying to simonh, and to be specific, to this part?

> I’ve tried many times over many years, but never got a satisfactory working Python + Qt development environment working on the Mac.

Why was this downvoted?

It will setup exactly what was asked for. Specifically qt 5.9.5 with PyQt.

conda install pyqt

Before I even look at the source code, what license is this under?

We've been discussing this, R users have asked for the same. The argument is that Anaconda should give them isolation. I think it should be opt-in though, probably. Tricky thing is that to do it you need to muck about in the internals of CPython and R and that'll upset some other people.

You can install R and some commonly used R packages with:

conda install r-essentials

Well, the Anaconda Distribution and conda-forge build many thousands of packages and they use a variety of (often programmable) build systems.

So quite often the build system will be mis-programmed or will simply not care for relocatability at all, hard-coding /usr/lib/libfoo.so as DT_NEEDED, or hard-coding /usr/lib as DT_RPATH and/or DT_RUNPATH.

So conda-build runs a post-build step to make all DSO loading relative. We use patchelf and install_name_tool for that on Linux and macOS respectively.

If you use conda-build it will do rpath fixups for you. You can also elect to specify that certain dependencies should come from the system. We do this for X11 for the Anaconda Distribution. To use these, in the recipe you list `cdt` (stands for Core Dependency Tree) packages as build dependencies. These packages are repackaged CentOS6 library and devel packages that are never installed on end-users machines, only at build time.

Official blog posts:

https://www.anaconda.com/blog/developer-blog/improved-securi...

https://www.anaconda.com/blog/developer-blog/announcing-the-...

https://www.anaconda.com/blog/developer-blog/utilizing-the-n...

I would recommend using conda-build to build packages, since it provides a lot of tooling to ensure things work well and to detect problems.

You can still create software by taring up the final ${PREFIX} if you wish, but if it's open source stuff then the best thing to do is to try to get the conda build recipes accepted by conda-forge.

The recipes that make the Anaconda Distribution can be found at: https://github.com/AnacondaRecipes/aggregate

A small correction: if you use our linux compilers, then the software you build will link to glibc 2.12 and will run on any Linux with glibc 2.12 and above.

BTW we also have our own macOS clang 4.0.1 based compilers and they both run on and generate software for macOS 10.9 and above. You need to provide your own macOS 10.9 SDK and point CONDA_BUILD_SYSROOT to where you unpack it (or use one you got with Xcode and risk lower backwards compatibility).

Anaconda provides more than Python libraries (C/C++ libraries, R packages).

The conda package manager can create isolated 'environments' (like virtualenv but not only for Python) that are very space efficient due to using hardlinks.

The conda-forge community has sprung up to develop recipes and provide packages. The Anaconda Distribution recipes are now actually built from github forks of these conda-forge recipes (we hope to achieve binary compatibility with them sometime soon).

There is no symbol table:

  bt full
  #0  0x00000000004212bb in do_mkvalue ()
  No symbol table info available.
  #1  0x00000000004210a7 in do_mktuple ()
  No symbol table info available.
  #2  0x00000000004211a8 in do_mkvalue ()
  No symbol table info available.
  #3  0x00000000004213f2 in vmkvalue ()
  No symbol table info available.
  #4  0x00000000004214a1 in mkvalue ()
  No symbol table info available.
  #5  0x0000000000422438 in err_input ()
  No symbol table info available.
  #6  0x000000000042258c in parse_file ()
  No symbol table info available.
  #7  0x00000000004226ae in run_file ()
  No symbol table info available.
  #8  0x0000000000422bf3 in run_script ()
  No symbol table info available.
  #9  0x000000000042232a in realmain ()
  No symbol table info available.
  #10 0x00000000004039f4 in main ()
  No symbol table info available.

Update: stack trace indicates it's trying to run a file, you can use -c to run some commands at least:

  python -c "print 'hello world'"

While we fix bugs in our Linux packages so they work on USW/WSL this one appears to have problems (and I do not expect I will look into them any time soon):

  Python 1.0.1 (Mar 26 2014)
  Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
  Segmentation fault (core dumped)

.. I did capture the backtrace though; for what it's worth:

  (gdb) bt
  #0  0x00000000004212bb in do_mkvalue ()
  #1  0x00000000004210a7 in do_mktuple ()
  #2  0x00000000004211a8 in do_mkvalue ()
  #3  0x00000000004213f2 in vmkvalue ()
  #4  0x00000000004214a1 in mkvalue ()
  #5  0x0000000000422438 in err_input ()
  #6  0x000000000042258c in parse_file ()
  #7  0x00000000004226ae in run_file ()
  #8  0x0000000000422bf3 in run_script ()
  #9  0x000000000042232a in realmain ()
  #10 0x00000000004039f4 in main ()

No it's a completely open source, built from source (using gcc) software distribution for Windows. It uses pacman to install packages and comes with many hundreds of prebuilt ones.

You can use `conda` cross-platform to install many C++ libraries.

Yes it does. By default it is case-preserving, case-insensitive but there is a registry key to enable case-sensitivity.

https://superuser.com/q/266110

We have put `ensurepip` back in place and uploaded new Python packages for all platforms. `conda update python` should see you right. Thank you for bringing this up.

It is also an unavoidable problem with GNU make and an easy to make mistake when writing CMake files. These tools should have required quoting up-front so filenames are never seen without them but it's a bit late in the day now to suggest fixing this.

While I agree with what you have said, as creators of a software distribution bundling software and a build system to build more software it would be remiss of us not to warn people when they try to install said software into a path containing spaces.

Though as @kalefranz said already, we do allow it on Windows, we just warn loudly.

It is very easy to write a bash script that completely mishandles variables containing filenames with spaces, for example:

cp ${FILENAME} /tmp

Here you should have done:

cp "${FILENAME}" /tmp

Also, GNU make, still one of the cornerstones of building C and C++ libraries (since CMake and Autotools most commonly use that backend) cannot handle spaces in paths at all well.