<p dir="auto">I cannot understand why the result of <code class="notranslate">take</code> can be visited by a for loop while throwing an error when put in a list comprehension, such as the code</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="for x in take(repeated(2), 10)
    println(x)
end"><pre class="notranslate"><code class="notranslate">for x in take(repeated(2), 10)
    println(x)
end
</code></pre></div>
<p dir="auto">works well but the following code</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="[x for x in take(repeated(2), 10)]"><pre class="notranslate"><code class="notranslate">[x for x in take(repeated(2), 10)]
</code></pre></div>
<p dir="auto">throws an error,</p>
<p dir="auto">LoadError: MethodError: <code class="notranslate">length</code> has no method matching length(::Base.Take{Base.Repeated{Int64}})<br>
while loading In[153], in expression starting on line 1</p>
<p dir="auto">in anonymous at no file</p>
<p dir="auto">AIUI, the Julia package manager currently allows only per-user installation of packages.</p>
<p dir="auto">From a packager perspective (I am a Debian developer), the possibility of having both system-wide and per user packages is very important.</p>
<p dir="auto">In Debian, we already distribute large parts of Python's PIP, Perl's CPAN, R's CPAN, Octave Forge,… through the package manager.</p>
<p dir="auto">I can give the following reasons for doing the same for Julia packages (the description below mentions Debian at several places, but you can replace it by virtually any GNU/Linux distributor):</p>
<ul dir="auto">
<li>uniformity of experience: a Debian user expects to get all its software through the Debian package manager (APT). Having to learn various package managers (Python's, Ruby's, Perl's, Octave's, R's,<br>
Emacs', Julia's…) seems redundant and a waste of time</li>
<li>getting dependencies easily: if a Julia package relies on some shared library, then installing it through APT would automatically pull the library; Julia's package manager obviously cannot do that</li>
<li>quality assurance and security: a Debian user typically trusts Debian Developpers to make various checks on the quality and security of a package before putting it in the Debian archive, so he will be more confident on the quality of a package that he gets through APT than through another mean; also, downloads from the Debian archive are GPG-signed, which gives the user more confidence into the fact the he downloaded an untampered piece of code</li>
<li>scalability: the Debian package manager makes it much easier to deploy large installations with either many users on a single machine or many similar machines (like in large educational centers or scientific organizations). The sysadmin will clearly prefer to install an extra Debian package (since this already fits into its workflow) than to install Julia packages in the home of every user. Duplicating installations of Julia packages is also a waste of storage space, and creates a greater potential for heterogeneous installs</li>
</ul>
<p dir="auto">Obviously the goal is not to package <em>all</em> Julia packages into Debian. Several criteria such as popularity, usefulness, maturity and stability will matter when making the decision to create a Debian package.</p>
<p dir="auto">Of course, the system needs to be designed in such a way that the per-user and system-wide repositories co-exist nicely. For example, if a package is installed in both locations, the per-user should probably take precedence (when executing a "Using" or when resolving dependencies).</p>
<p dir="auto">In designing the system, it is important to recall that from user perspective, the system-wide location is read-only.</p>