You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
create new fpb_env package with fixed dependencies #704
Not at this point as it is useful for people outside the fpb (eg croatians). If its maintenance takes too much time, we can always re-evaluate that later.
Unsure. I guess a package, so that we can provide a Windows menu to upgrade it, or is that possible with a metapackage too? On the long run, I suppose a package will be better anyway because I guess that at some point we will want to add FPB-specific pieces of code there that are not large enough to warrant creating a separate package for them.
This issue is really a pain and I am a bit stuck with it.
On one hand, not having a solution for this keeps being a problem over and over. New installs, or users installing another package and getting updated dependencies which conflicts with LArray in some way (usually via new warnings but sometimes with a crash).
On the other hand our users also need to install miscellany packages on top of larrayenv (scipy, pyarrow, rpy2, statsmodels, sympy, yaml, ...) and having very strict version requirements would in some cases make installing those packages impossible. So one solution would be to include all those packages in our mega-package... but some of those packages do not exist in anaconda or are so outdated they are inusable. The solution to that is to switch to either conda-forge (and keep using conda) or to pip.
pip usually has all packages and all their versions.
conda-forge currently has a lot more packages than anaconda, and they are relatively quickly updated.
The problem with both is the flip-side of the advantage of being community-maintained: there is no gatekeeping by Anaconda Inc => there is a higher risk -- at least the way I see it -- of a compromised package getting through either directly when users install more packages (hard because of the strict dependencies versions but not impossible) or, in our machine, most likely via one of our indirect dependencies when we produce updated packages.
One solution to the "users installing new packages" problem is to prevent them from doing so and produce a new version of our mega package with ever more packages each time one user needs an extra package. One option to do this would be to create offline installers containing all packages using conda constructor (https://github.com/conda/constructor - https://conda.github.io/constructor/howto/).
Activity
alixdamman commentedon May 28, 2019
See also #767
fix larray-project#704 : added constraints on package versions in com…
[-]fix dependencies in larrayenv[/-][+]create new fpb_env package with fixed dependencies[/+]alixdamman commentedon May 29, 2019
@gdementen
Question 1: Do you want to remove larrayenv?
Question 2: fpb_env should be a package or a metapackage?
gdementen commentedon May 29, 2019
2 remaining items
gdementen commentedon Oct 25, 2023
This issue is really a pain and I am a bit stuck with it.
On one hand, not having a solution for this keeps being a problem over and over. New installs, or users installing another package and getting updated dependencies which conflicts with LArray in some way (usually via new warnings but sometimes with a crash).
On the other hand our users also need to install miscellany packages on top of larrayenv (scipy, pyarrow, rpy2, statsmodels, sympy, yaml, ...) and having very strict version requirements would in some cases make installing those packages impossible. So one solution would be to include all those packages in our mega-package... but some of those packages do not exist in anaconda or are so outdated they are inusable. The solution to that is to switch to either conda-forge (and keep using conda) or to pip.
The problem with both is the flip-side of the advantage of being community-maintained: there is no gatekeeping by Anaconda Inc => there is a higher risk -- at least the way I see it -- of a compromised package getting through either directly when users install more packages (hard because of the strict dependencies versions but not impossible) or, in our machine, most likely via one of our indirect dependencies when we produce updated packages.
One solution to the "users installing new packages" problem is to prevent them from doing so and produce a new version of our mega package with ever more packages each time one user needs an extra package. One option to do this would be to create offline installers containing all packages using conda constructor (https://github.com/conda/constructor - https://conda.github.io/constructor/howto/).
In the pip world, I think our best bet would be to run our own private pypi repository (https://packaging.python.org/en/latest/guides/hosting-your-own-index/). Unsure how hard/how much effort it would mean to keep that running.