Is it possible to self host elm packages like gems or nuggets?
The team already agreed to use it, but with our proxy we cant install packages.
thank you for the support
What you can do is to clone the library your are looking for in the elm package manager cache.
However, I don't know how you will be able to manage to create the version.dat file.
Maybe copy it from another computer?
~/.elm$ tree -L 5
.
└── 0.19.0
└── package
├── ContaSystemer
│ └── elm-menu
│ └── 1.0.2
├── elm
│ ├── browser
│ │ └── 1.0.1
│ ├── bytes
│ │ └── 1.0.7
│ ├── core
│ │ └── 1.0.2
│ ├── file
│ │ └── 1.0.1
│ ├── html
│ │ └── 1.0.0
│ ├── http
│ │ └── 2.0.0
│ ├── json
│ │ └── 1.1.2
│ ├── parser
│ │ └── 1.1.0
│ ├── random
│ │ └── 1.0.0
│ ├── regex
│ │ └── 1.0.0
│ ├── time
│ │ └── 1.0.0
│ ├── url
│ │ └── 1.0.0
│ └── virtual-dom
│ └── 1.0.0
├── elm-community
│ ├── list-extra
│ │ └── 8.1.0
│ └── string-extra
│ └── 4.0.0
├── elm-explorations
│ └── test
│ └── 1.0.0
├── goilluminate
│ └── elm-fancy-daterangepicker
│ └── 4.0.0
├── justinmimbs
│ └── date
│ └── 3.1.2
├── NoRedInk
│ └── elm-json-decode-pipeline
│ └── 1.0.0
├── rtfeldman
│ ├── elm-hex
│ │ └── 1.0.0
│ └── elm-iso8601-date-strings
│ └── 1.1.2
├── Skinney
│ └── murmur3
│ └── 2.0.7
├── terezka
│ └── yaml
│ └── 1.0.0
├── truqu
│ └── elm-base64
│ └── 2.0.4
└── versions.dat
Related
I have two packages inside my npm workspace api & cdk. I would like to create an individual package-lock.json inside api & cdk as both of those projects will get deployed individually. Is this currently possible with npm workspaces? What are other alternatives or strategies?
├── api
│ ├── package.json
├── cdk
│ ├── package.json
├── node_modules
├── package.json
├── package-lock.json
I have workspaces configured and working.
When I install from the root, sometimes packages are installed in the root and sometimes they are installed in the workspace node_modules.
When and how does NPM choose to install a package at the root/node_modules vs a workspace/node_modules?
It turns out, when two packages rely on the same module with a compatible version number in the dependencies, npm (with workspaces) will install the package only in root/node_modules. Otherwise, it will install in the node_modules of package(s).
In this example the same react-dom version is shared between packages:
customer-ui#1.0.0 /home/ubuntu/name/customer-ui
├─┬ components#0.15.0 -> ./packages/components
│ ├─┬ react-cosmos#5.7.2
│ │ └─┬ react-cosmos-shared2#5.7.1
│ │ └─┬ react-element-to-jsx-string#14.3.4
│ │ └── react-dom#17.0.2 deduped
│ ├── react-dom#17.0.2
│ ├─┬ react-modal#3.15.1
│ │ └── react-dom#17.0.2 deduped
│ ├─┬ react-to-print#2.14.7
│ │ └── react-dom#17.0.2 deduped
│ └─┬ styled-components#5.3.5
│ └── react-dom#17.0.2 deduped
└─┬ embedded#0.1.0 -> ./packages/embedded
└── react-dom#17.0.2 deduped
And npm installed it only in the root/node_modules dir:
❯ ls node_modules/react-dom
LICENSE build-info.json index.js profiling.js server.js test-utils.js
README.md cjs package.json server.browser.js server.node.js umd
❯ ls packages/embedded/node_modules/react-dom
ls: cannot access 'packages/embedded/node_modules/react-dom': No such file or directory
❯ ls packages/components/node_modules/react-dom
ls: cannot access 'packages/components/node_modules/react-dom': No such file or directory
However, for a package with incompatible version between packages, it's different:
❯ npm ls argparse
customer-ui#1.0.0 /home/ubuntu/name/customer-ui
├─┬ #components#0.15.0 -> ./packages/components
│ └─┬ eslint#8.17.0
│ └─┬ js-yaml#4.1.0
│ └── argparse#2.0.1
└─┬ embedded#0.1.0 -> ./packages/embedded
├─┬ eslint#6.8.0
│ └─┬ js-yaml#3.14.1
│ └── argparse#1.0.10
├─┬ jest-preset-preact#4.0.5
│ └─┬ babel-jest#27.5.1
│ └─┬ babel-plugin-istanbul#6.1.1
│ └─┬ #istanbuljs/load-nyc-config#1.1.0
│ └─┬ js-yaml#3.14.1
│ └── argparse#1.0.10
└─┬ microbundle#0.12.4
├─┬ cssnano#4.1.11
│ ├─┬ cosmiconfig#5.2.1
│ │ └─┬ js-yaml#3.14.1
│ │ └── argparse#1.0.10
│ └─┬ cssnano-preset-default#4.0.8
│ └─┬ postcss-svgo#4.0.3
│ └─┬ svgo#1.3.2
│ └─┬ js-yaml#3.14.1
│ └── argparse#1.0.10
└─┬ rollup-plugin-postcss#2.9.0
└─┬ postcss-load-config#2.1.2
└─┬ cosmiconfig#5.2.1
└─┬ js-yaml#3.14.1
└── argparse#1.0.10
embedded package demands argparse#1.0.10 and embedded demands argparse#2.0.1.
For these, npm installs them in multiple places:
❯ ls node_modules/argparse
CHANGELOG.md LICENSE README.md argparse.js lib package.json
❯ ls packages/components/argparse
ls: cannot access 'packages/components/argparse': No such file or directory
❯ ls packages/embedded/node_modules/argparse
CHANGELOG.md LICENSE README.md index.js lib package.json
In case it helps, this is a snippet of root/package.json:
{
"name": "customer-ui",
"version": "1.0.0",
"workspaces": [
"packages/*"
]
}
Thanks to #Stf_F for answering this in the comment above.
I have a project where some f90 files need to be compiled using the regular gfortran compiler and some need to be compiled by using the mpifort wrapper. I don't know how to properly write the CMake file to accomodate this. Also, I have never used CMake before and am not familiar with it, but I'm trying to understand from documentation and (largely outdated) tutorials.
My project directory looks as follows:
├── CMakeLists.txt
├── README.md
├── bin
├── build
├── compile
├── src
│ ├── CMakeCache.txt
│ ├── CMakeFiles
│ │ ├── 3.8.1
│ │ │ ├── CMakeCCompiler.cmake
│ │ │ ├── CMakeCXXCompiler.cmake
│ │ │ ├── CMakeDetermineCompilerABI_C.bin
│ │ │ ├── CMakeDetermineCompilerABI_CXX.bin
│ │ │ ├── CMakeDetermineCompilerABI_Fortran.bin
│ │ │ ├── CMakeFortranCompiler.cmake
│ │ │ ├── CMakeSystem.cmake
│ │ │ ├── CompilerIdC
│ │ │ │ ├── CMakeCCompilerId.c
│ │ │ │ ├── a.out
│ │ │ │ └── tmp
│ │ │ ├── CompilerIdCXX
│ │ │ │ ├── CMakeCXXCompilerId.cpp
│ │ │ │ ├── a.out
│ │ │ │ └── tmp
│ │ │ └── CompilerIdFortran
│ │ │ ├── CMakeFortranCompilerId.F
│ │ │ ├── a.out
│ │ │ └── tmp
│ │ ├── CMakeDirectoryInformation.cmake
│ │ ├── CMakeOutput.log
│ │ ├── CMakeTmp
│ │ ├── Makefile.cmake
│ │ ├── Makefile2
│ │ ├── TargetDirectories.txt
│ │ ├── cmake.check_cache
│ │ ├── feature_tests.bin
│ │ ├── feature_tests.c
│ │ ├── feature_tests.cxx
│ │ ├── progress.marks
│ │ └── streetcanyon.dir
│ │ ├── DependInfo.cmake
│ │ ├── INC_BBB.f90.o
│ │ ├── INC_BBB.f90.o.provides.build
│ │ ├── INC_BC.f90.o
│ │ ├── INC_BC.f90.o.provides.build
│ │ ├── INC_BOUNDC.f90.o
│ │ ├── INC_BOUNDC.f90.o.provides.build
│ │ ├── INC_BUOY.f90.o
│ │ ├── INC_BUOY.f90.o.provides.build
│ │ ├── INC_COEF.f90.o
│ │ ├── INC_COEF.f90.o.provides.build
│ │ ├── INC_COEFB.f90.o
│ │ ├── INC_COEFB.f90.o.provides.build
│ │ ├── INC_GEO.f90.o
│ │ ├── INC_GEO.f90.o.provides.build
│ │ ├── INC_INDEX.f90.o
│ │ ├── INC_INDEX.f90.o.provides.build
│ │ ├── INC_OBSTACLE.f90.o
│ │ ├── INC_OBSTACLE.f90.o.provides.build
│ │ ├── INC_PAR.f90.o
│ │ ├── INC_PAR.f90.o.provides.build
│ │ ├── INC_PRINT.f90.o
│ │ ├── INC_PRINT.f90.o.provides.build
│ │ ├── INC_SOURCE.f90.o
│ │ ├── INC_SOURCE.f90.o.provides.build
│ │ ├── INC_STAT.f90.o
│ │ ├── INC_STAT.f90.o.provides.build
│ │ ├── INC_TIME.f90.o
│ │ ├── INC_TIME.f90.o.provides.build
│ │ ├── INC_TITLE.f90.o
│ │ ├── INC_TITLE.f90.o.provides.build
│ │ ├── INC_TREES.f90.o
│ │ ├── INC_TREES.f90.o.provides.build
│ │ ├── INC_UVW.f90.o
│ │ ├── INC_UVW.f90.o.provides.build
│ │ ├── INC_VEC.f90.o
│ │ ├── INC_VEC.f90.o.provides.build
│ │ ├── INC_WALL.f90.o
│ │ ├── INC_WALL.f90.o.provides.build
│ │ ├── build.make
│ │ ├── cmake_clean.cmake
│ │ ├── cmake_clean_Fortran.cmake
│ │ ├── depend.internal
│ │ ├── depend.make
│ │ ├── flags.make
│ │ ├── fortran.internal
│ │ ├── inc_bbb.mod.stamp
│ │ ├── inc_bc.mod.stamp
│ │ ├── inc_boundc.mod.stamp
│ │ ├── inc_buoy.mod.stamp
│ │ ├── inc_coef.mod.stamp
│ │ ├── inc_coefb.mod.stamp
│ │ ├── inc_geo.mod.stamp
│ │ ├── inc_index.mod.stamp
│ │ ├── inc_obstacle.mod.stamp
│ │ ├── inc_par.mod.stamp
│ │ ├── inc_print.mod.stamp
│ │ ├── inc_source.mod.stamp
│ │ ├── inc_stat.mod.stamp
│ │ ├── inc_time.mod.stamp
│ │ ├── inc_title.mod.stamp
│ │ ├── inc_trees.mod.stamp
│ │ ├── inc_uvw.mod.stamp
│ │ ├── inc_vec.mod.stamp
│ │ ├── inc_wall.mod.stamp
│ │ ├── link.txt
│ │ └── progress.make
│ ├── INC_BBB.f90
│ ├── INC_BC.f90
│ ├── INC_BOUNDC.f90
│ ├── INC_BUOY.f90
│ ├── INC_COEF.f90
│ ├── INC_COEFB.f90
│ ├── INC_GEO.f90
│ ├── INC_INDEX.f90
│ ├── INC_OBSTACLE.f90
│ ├── INC_PAR.f90
│ ├── INC_PAR.f90_8ob
│ ├── INC_PRINT.f90
│ ├── INC_SOURCE.f90
│ ├── INC_STAT.f90
│ ├── INC_TIME.f90
│ ├── INC_TITLE.f90
│ ├── INC_TREES.f90
│ ├── INC_UVW.f90
│ ├── INC_VEC.f90
│ ├── INC_WALL.f90
│ ├── Makefile
│ ├── cmake_install.cmake
│ ├── grid_binary
│ ├── grid_binary(8\ obsttacles)
│ ├── inc_bbb.mod
│ ├── inc_bc.mod
│ ├── inc_boundc.mod
│ ├── inc_buoy.mod
│ ├── inc_coef.mod
│ ├── inc_coefb.mod
│ ├── inc_geo.mod
│ ├── inc_index.mod
│ ├── inc_obstacle.mod
│ ├── inc_par.mod
│ ├── inc_print.mod
│ ├── inc_source.mod
│ ├── inc_stat.mod
│ ├── inc_time.mod
│ ├── inc_title.mod
│ ├── inc_trees.mod
│ ├── inc_uvw.mod
│ ├── inc_vec.mod
│ ├── inc_wall.mod
│ ├── mpi_par.f90
│ ├── source
│ ├── streetcanyon.f90
│ └── streetcanyon.f90~
In the ./src/ directory the streetcanyon.f90 and mpi_par.f90 need to be compiled using mpifort, the rest can be done through gfortran. streetcanyon.f90 needs to be compiled to the final executable. I have tried using the following CMakeList.txt which is contained in the project root dir:
#./CMakeList.txt
cmake_minimum_required (VERSION 3.8.0)
project(mpi)
enable_language (Fortran)
file(GLOB SOURCES src/*.f90)
add_executable(streetcanyon ${SOURCES})
I also don't know if I'm following the appropriate project structure for Fortran.
Just use CMake's FindMPI module. It will extract the compile flags and libraries from mpifort and make them available as regular CMake variables. All you have to do is apply those flags to your library. The only hard part is that there are several different things that have to get applied. Here's an example of how you'd use it:
cmake_minimum_required (VERSION 3.8.0)
project(mpi)
enable_language (Fortran)
find_package(MPI)
if(NOT MPI_Fortran_FOUND)
message(FATAL_ERROR "Could not find Fortran MPI. Please set MPI_Fortran_COMPILER to point to the mpifort wrapper.")
endif()
include_directories(${MPI_Fortran_INCLUDE_PATH})
add_compile_options(${MPI_Fortran_COMPILE_FLAGS})
file(GLOB SOURCES src/*.f90)
add_executable(streetcanyon ${SOURCES})
target_link_libraries(streetcanyon ${MPI_Fortran_LIBRARIES})
set_property(TARGET streetcanyon APPEND_STRING PROPERTY LINK_FLAGS "${MPI_Fortran_LINK_FLAGS}")
This will compile all of the streetcanyon sources the way that mpifort would have compiled them, which should be fine in 99% of use cases. If you really want to only compile some files like mpifort would have, like you said, then instead of
add_compile_options(${MPI_Fortran_COMPILE_FLAGS})
you can pass the MPI compile options to specific source files only, with a bit of fiddling:
set(MPI_SOURCES foo.f90 bar.f90...)
set(NO_MPI_SOURCES baz.f90...)
# convert CMake list to string for PROPERTY COMPILE_FLAGS
set(MPI_Fortran_COMPILE_FLAGS_STR "")
foreach(ELEMENT ${MPI_Fortran_COMPILE_FLAGS})
set(MPI_Fortran_COMPILE_FLAGS_STR "${MPI_Fortran_COMPILE_FLAGS_STR } ${ELEMENT}")
endforeach()
set_property(SOURCE ${MPI_SOURCES} PROPERTY COMPILE_FLAGS ${MPI_Fortran_COMPILE_FLAGS_STR})
...later...
add_executable(streetcanyon ${MPI_SOURCES} ${NO_MPI_SOURCES})
I try to get into the tutorial of React Native but I am stuck at init a new project. A npm error occurs npm ERR! enoent ENOENT: no such file or directory, open '/Users/vikti/dev/AwesomeProject/node_modules/.staging/xtend-ea557a9c3da42553dd204c5fe8fb762c/package.json'
Here is the log:
MacBook-Pro-de-vikti:dev vikti$ react-native init AwesomeProject
This will walk you through creating a new React Native project in /Users/vikti/dev/AwesomeProject
AwesomeProject#0.0.1 /Users/vikti/dev/AwesomeProject
├── absolute-path#0.0.0 extraneous
├── archive-type#3.0.1 extraneous
├── babel-core#5.8.21 extraneous
├── beeper#1.1.0 extraneous
├── bl#1.0.0 extraneous
├── bser#1.0.0 extraneous
├── buffer-to-vinyl#1.0.1 extraneous
├── caw#1.1.0 extraneous
├── chokidar#1.2.0 extraneous
├── cli-table#0.3.1 extraneous
├── commondir#1.0.1 extraneous
├── connect#2.8.3 extraneous
├── cross-spawn#2.0.0 extraneous
├── dargs#4.0.1 extraneous
├── dateformat#1.0.11 extraneous
├── detect-conflict#1.0.0 extraneous
├── diff#1.4.0 extraneous
├── each-async#1.1.1 extraneous
├── ejs#2.3.4 extraneous
├── errno#0.1.4 extraneous
├── filenamify#1.2.0 extraneous
├── findup-sync#0.2.1 extraneous
├── github-username#2.0.0 extraneous
├── glob-watcher#0.0.8 extraneous
├── glob2base#0.0.12 extraneous
├── globby#2.1.0 extraneous
├── got#4.2.0 extraneous
├── grouped-queue#0.3.0 extraneous
├── gruntfile-editor#1.0.0 extraneous
├── gulp-rename#1.2.2 extraneous
├── html-wiring#1.2.0 extraneous
├── image-size#0.3.5 extraneous
├── immutable#3.7.5 extraneous
├── inquirer#0.8.5 extraneous
├── is-bzip2#1.0.0 extraneous
├── is-gzip#1.0.0 extraneous
├── is-tar#1.0.0 extraneous
├── is-url#1.2.1 extraneous
├── is-zip#1.0.0 extraneous
├── istextorbinary#1.0.2 extraneous
├── joi#5.1.0 extraneous
├── lodash._reescape#3.0.0 extraneous
├── lodash._reevaluate#3.0.0 extraneous
├── lodash.template#3.6.2 extraneous
├── log-symbols#1.0.2 extraneous
├── module-deps#3.5.6 extraneous
├── multimatch#2.0.0 extraneous
├── multipipe#0.1.2 extraneous
├── nopt#3.0.4 extraneous
├── optimist#0.6.1 extraneous
├── ordered-read-streams#0.1.0 extraneous
├── pretty-bytes#2.0.1 extraneous
├── progress#1.1.8 extraneous
├── promise#7.0.4 extraneous
├── react-timer-mixin#0.13.3 extraneous
├── react-tools#0.14.0-beta1 extraneous (git://github.com/facebook/react.git#b4e74e38e43ac53af8acd62c78c9213be0194245)
├── rebound#0.0.12 extraneous
├── regenerator#0.8.36 extraneous
├── rimraf#2.4.3 extraneous
├── run-async#0.1.0 extraneous
├── sane#1.3.0 extraneous
├── seek-bzip#1.0.5 extraneous
├── shelljs#0.5.3 extraneous
├── sinon#1.17.1 extraneous
├── stacktrace-parser#0.1.3 extraneous
├── stat-mode#0.2.1 extraneous
├── strip-dirs#1.1.1 extraneous
├── text-table#0.2.0 extraneous
├── uglify-js#2.4.16 extraneous
├── underscore#1.7.0 extraneous
├── underscore.string#3.2.2 extraneous
├── untildify#2.1.0 extraneous
├── vinyl#0.4.6 extraneous
├── vinyl-assign#1.2.1 extraneous
├── vinyl-file#1.2.1 extraneous
├── ware#1.3.0 extraneous
├── wordwrap#1.0.0 extraneous
├── ws#0.8.0 extraneous
├── xdg-basedir#2.0.0 extraneous
├── yauzl#2.3.1 extraneous
├── yeoman-assert#2.1.0 extraneous
└── yeoman-welcome#1.0.1 extraneous
npm ERR! Darwin 14.4.0
npm ERR! argv "/Users/vikti/.nvm/versions/node/v4.1.1/bin/node" "/Users/vikti/.nvm/versions/node/v4.1.1/bin/npm" "install" "--save" "react-native"
npm ERR! node v4.1.1
npm ERR! npm v3.3.5
npm ERR! path /Users/vikti/dev/AwesomeProject/node_modules/.staging/xtend-ea557a9c3da42553dd204c5fe8fb762c/package.json
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall open
npm ERR! enoent ENOENT: no such file or directory, open '/Users/vikti/dev/AwesomeProject/node_modules/.staging/xtend-ea557a9c3da42553dd204c5fe8fb762c/package.json'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent
npm ERR! Please include the following file with any support request:
npm ERR! /Users/vikti/dev/AwesomeProject/npm-debug.log
Any idea on what is wrong?
I used npm install --dev to install the dependencies listed in a package.json file and it seems that rather than installing all the packages in a flat structure, it is installing the dependencies of each module inside the module's directory.
I had to cancel it because it was taking a lot, because many dependencies should have been already satisfied but it had to re-download them in a different nested directory (and I hope that there are not loops and it would have eventually finished)...
Using the tree command this is an example of what I am getting:
├── grunt-cli
│ └── node_modules
│ ├── findup-sync
│ │ └── node_modules
│ │ ├── glob
│ │ │ └── node_modules
│ │ │ ├── minimatch
│ │ │ │ └── node_modules
│ │ │ │ ├── lru-cache
│ │ │ │ │ └── node_modules
│ │ │ │ │ └── weak
│ │ │ │ │ └── node_modules
│ │ │ │ │ └── mocha
│ │ │ │ │ └── node_modules
│ │ │ │ │ ├── coffee-script
│ │ │ │ │ │ └── node_modules
│ │ │ │ │ │ └── jison
│ │ │ │ │ │ └── node_modules
│ │ │ │ │ │ └── browserify
│ │ │ │ │ │ └── node_modules
│ │ │ │ │ │ ├── browser-resolve
│ │ │ │ │ │ │ └── example
Any ideas why this might be happening?
Don't worry, that's actually the way Npm was designed. You may even see the same module installed many times (though typically with different versions).
The idea is that each module installed under node_modules is a somewhat self-contained installation of that module with its dependencies and the necessary versions -- it doesn't depend on modules installed globally.
If you are worried about inefficiency of modules being installed multiple times, the experimental npm dedupe.
dedupe is helpful, as Jonathan Warden says. However, try npm3. For a simple package such as gulp-jscs the install of npm3 was 20% fewer files, 5% less disk space. And tree depth went from 22 to 5. However npm3 was 2x slower for me.