do you know python resolve dependency by downloading multiple versions of different packages and try out? 
1 Like
PyCall remembers which Python you set it up with for subsequent builds/updates. If you set it up to use your system Python, it should never install its own Anaconda distro in a subsequent update unless you change the setting explicitly by setting the PYTHON environment variable.
3 Likes
Again, I’m mostly talking about compilation options that affect performance. So it makes total sense to have the default binary without ffast-math (less so for march native…), but for willing users adding such options should be possible.
Not sure where did you get this suggestion in my comment.
So? It definitely allows to modify compilation options, which is my point.
Note that I’m not talking about ygg at all, didn’t mention it even once!
I just wish there was a reasonably-simple way to modify compilation options for a jll binary B_jll which is used from Julia package P1 which is used from P2. Overrides mechanism likely allows to substitute the pre-built jll with another binary, but I didn’t really understand how it should be used and how easy it is…
2 Likes
totally agree, but as pointed out, it looks like this has never been a deal-breaking thing, ever,
Of course, real “deal-breakers” are very rare and uncommon. E.g. non-existence of real programming languages and libraries were not deal-breakers for solving many problems, but now most prefer writing in something higher level than machine code 
1 Like
By coincidence, I found this today on HN. I think it’s at least tangentially relevant: Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies | by Alex Birsan | Medium
1 Like
That is something that is currently being discussed for Pkg.jl, but it’s not really related to BB directly.
1 Like
Because it is assuming that nothing exist outside julia and is unwilling to work with anything else.
It doesn’t if you have something else that also makes the same assumption. If two projects A and B both requires two different exact source of binary to work, there’s no way for the two to work with each other. And the reason for that is because both projects have made an incredibly selfish decision. This is very different from a version requirement, which is usually a range and usually for much fewer libraries. Anything that requires an exact version of 3-rd party library is almost as bad, but this is much work due to the scope.
And as I said, it would not have been a problem if this didn’t work before and if there hasn’t been comments about being proud of breaking my working setup and regarding the way I’d like to have julia interact with my system as unimportant and non-existing.
Which is totally fine. And which is also I have been totally fine with having a solution that just work for 99% of the people, especially since more than 90% of people are using windows and lack a working package manager anyway. It is when people assume 99% == 100% and start to break it for the rest 1% and say they never existed that is the big problem.
No it has absolutely nothing to do with either. And especially not about harddrive space which I explicitly mentioned above already. It may share concerns with HPC admin but I know nothing about their constraints.
It’s about being able to build julia and all the packages so that it’ll use the system libraries automatically. It used to work and it has been working with some hack until a few month ago and it was intentionally broken since it’s “not the kind of build we like to create.”.
1 Like