<personal-opinion> I don't think you should support Anaconda Python. I realize it is convenient. Providing a sort of private copy of Python and its packages makes sense. It simplifies installation and maintenance of key Julia dependencies for users. I just don't think you should use Anaconda to do it.
Anaconda is fork of Python, its package management, its primary package repository, and many of the packages themselves. Forks are BAD. It borders on a commercial lock-in or, at a minimum, a technical lock-in to Anaconda. I am a commercial software guy by experience. I made a living from commercial software and find that to be completely honorable. This is not an anti-commercial rant. It IS, on the other hand, an anti-fork rant. Python is a vibrant community. Julia is a vibrant community on a very nice trajectory. May they both continue. Rather than a philosophical discussion of Continuum and various open source license types, lets think about this from the standpoint of Julia. Would you like it if someone came along and forked all of Julia, especially Pkg, and created forks of every package? To do so would be entirely compliant with the MIT open source license. So, it would be legal (not that license enforcement is common in the open source world). But, would it be DESIRABLE? You've done a fine thing to rely largely on git and github. Probably not. Is it possible that someone proposing enhancements found that their suggestions were rejected? Well, that can happen. Perhaps that would lead to a fork. But, if there was community endorsement of the suggestions from some reasonable plurality of members and enhancements could be made without injury to those preferring some other code path, it would be reasonable to accommodate particularly if the proposers backed their suggestions with effort--working code that could be integrated under the conditions mentioned. I depict this in a somewhat negative way, but my point is to confirm that *contributing is better than forking*. Typically, it is easier--and less negative--than the scenario I depicted. There is a community. Some leaders are very technically adept and have a vision (e.g., Julia is not C, Python, R, or Java so it won't do things just like those or other languages...) so they have some sway over final inclusion decisions. And these technical leaders do care what the community suggests; are open to suggestions and contributions; occasionally reject some input with transparent reasons (transparency may not convince the proposer, but it is good for everyone to see the dialog and decisions); and often accept suggestions--implementing the suggestions themselves or accepting pull requests. But, realistically the core team makes most of the commits and carries most of the work. This is probably how we want it to work. We probably don't want a fork of Julia and hope to avoid it and we will see Julia grow and be enhanced--most often on the path and vision of the founders and sometimes with the contributions of others. In the spirt of "do unto others...", let's not encourage a fork of Python. This would mean using Python releases of the Python Software Foundation (PSF) and its package repository PyPI. There will be some inconvenience. Perhaps not all of the Python "cousins" are enamored of Julia and aren't eager to be helpful. Or perhaps they are merely neutral and busy. But, it supports their community to endorse it. Do unto others... As a serious practical matter, the communities are not distinct. Many user-developers do use both Julia and Python. We'd like both communities to thrive. I think Continuum would probably concur with the broad sentiment, though not with my personal opinion about using Anaconda as a Julia dependency. This requires some deep thought. Using Anaconda is certainly a near-term convenience. On Windows, it is possible to get most of the same benefits from the less commercially oriented release WinPython. On Mac, ...from Homebrew, which is also quite non-commercial. On Linux, ...well, that is another kettle of fragmentation--and probably better to rely on PSF than a bunch of package repositories. Consider: how do you want the Julia community to develop? How does the Julia community overlap with the Python community (and to a lesser extent the R community)? How do choices affect the healthy, long-term evolution of an open source community? </personal opinion> I've left out discussion of how open source communities can attract commercial participants. That is indeed beneficial. Look to Cloudera's role in the Hadoop community for a good example of how this can work.
