dependencies   1930

« earlier    

How to Set Up a Private Maven Repository in Amazon S3
Amazon S3 is a perfect place for keeping private Maven artifacts, automatically deploying them there, and making them available through s3auth.com.
amazon  dependencies  java  maven  private  repository  s3  s3auth  s3wagon 
3 days ago by devnulled
README/dependencies.md at master · artsy/README
In general we want to have a conservative dependency policy, which can be summed up as: (1) Is it worth the time it saves? (In terms of API surface area, runtime cost, complexity.) (2) Does it neatly fit the current problem domain, and are we likely to use the other parts? (3) If it becomes un-maintained, can we take over?
dependencies  architecture  projects  projectmanagement  leadership  technology  bestpractices 
6 days ago by dlkinney
sonatype-nexus-community/nancy: A tool to check for vulnerabilities in your Golang dependencies, powered by Sonatype OSS Index
A tool to check for vulnerabilities in your Golang dependencies, powered by Sonatype OSS Index - sonatype-nexus-community/nancy
golang  security  dependencies 
10 days ago by geetarista
Dependabot
Automated dependency updates for your Ruby, Python, JavaScript, PHP, .NET, Go, Elixir, Rust, Java and Elm.
PHP  automation  bundler  composer  dependencies  dependency  github  javascript  nodejs  npm  pip  python  ruby  service  update  yarn 
13 days ago by ngaloppo
Good Makefiles | Gustav Louw
GNU Makefiles and C. One just needs a good template:
template  howto  advice  makefiles  best_practices  dependencies 
14 days ago by jbkcc
sdispater/poetry: Python dependency management and packaging made easy.
poetry is a tool to handle dependency installation as well as building and packaging of Python packages. It only needs one file to do all of that: the new, standardized pyproject.toml.

In other words, poetry uses pyproject.toml to replace setup.py, requirements.txt, setup.cfg, MANIFEST.in and the newly added Pipfile.
python  packaging  dependency_management  tool  is:repo  dependencies 
19 days ago by cdzombak
PEP 518 -- Specifying Minimum Build System Requirements for Python Projects | Python.org
This PEP specifies how Python software packages should specify what build dependencies they have in order to execute their chosen build system. As part of this specification, a new configuration file is introduced for software packages to use to specify their build dependencies (with the expectation that the same configuration file will be used for future configuration details).

This PEP attempts to rectify the situation by specifying a way to list the minimal dependencies of the build system of a project in a declarative fashion in a specific file. This allows a project to list what build dependencies it has to go from e.g. source checkout to wheel, while not falling into the catch-22 trap that a setup.py has where tooling can't infer what a project needs to build itself. Implementing this PEP will allow projects to specify what build system they depend on upfront so that tools like pip can make sure that they are installed in order to run the build system to build the project.

To provide more context and motivation for this PEP, think of the (rough) steps required to produce a built artifact for a project:

1. The source checkout of the project.
2. Installation of the build system.
3. Execute the build system.

This PEP covers step #2. PEP 517 covers step #3, including how to have the build system dynamically specify more dependencies that the build system requires to perform its job. The purpose of this PEP though, is to specify the minimal set of requirements for the build system to simply begin execution.
python  dependencies  dependency_management  setuptools  distutils  pip 
19 days ago by cdzombak
research!rsc: Our Software Dependency Problem
The kind of critical examination of specific dependencies that I outlined in this article is a significant amount of work and remains the exception rather than the rule. But I doubt there are any developers who actually make the effort to do this for every possible new dependency. I have only done a subset of them for a subset of my own dependencies. Most of the time the entirety of the decision is “let’s see what happens.” Too often, anything more than that seems like too much effort.

But the Copay and Equifax attacks are clear warnings of real problems in the way we consume software dependencies today. We should not ignore the warnings. I offer three broad recommendations.

* Recognize the problem. If nothing else, I hope this article has convinced you that there is a problem here worth addressing. We need many people to focus significant effort on solving it.

* Establish best practices for today. We need to establish best practices for managing dependencies using what’s available today. This means working out processes that evaluate, reduce, and track risk, from the original adoption decision through to production use. In fact, just as some engineers specialize in testing, it may be that we need engineers who specialize in managing dependencies.

* Develop better dependency technology for tomorrow. Dependency managers have essentially eliminated the cost of downloading and installing a dependency. Future development effort should focus on reducing the cost of the kind of evaluation and maintenance necessary to use a dependency. For example, package discovery sites might work to find more ways to allow developers to share their findings. Build tools should, at the least, make it easy to run a package’s own tests. More aggressively, build tools and package management systems could also work together to allow package authors to test new changes against all public clients of their APIs. Languages should also provide easy ways to isolate a suspect package.
dependencies  software  coding  work 
24 days ago by jm

« earlier    

related tags

2018  _toread  advice  agile  alternative  amazon  amsterdam  andrew  android  androidstudio-plugin  angular  app  apt  architecture  article  artsy  atlas  automation  awslambda  bazel  benchmarks  best_practices  bestpractices  bitbucket  bot  bundler  caching  check  ci  circular  cli  clojure  code  coding  comparisons  composer  conflicts  container  continuous_integration  critique  custom  decisions  dependecy-manager  dependency-management  dependency  dependency_management  dependencyhell  dependencymanagement  deployment  deps  devel  development  distributed  distutils  docker  dotnet  download  ecmascript  emacs  es  es6  esm  evaluation  events  export  exports  fast  get  git  github  go  golang  google  gradle  graphs  hestia  hootsuite  howto  hugo  ifttt  immutability  import  important  injection  insights  installer  intellij  ioc  is:repo  is:video  jar  java  javascript  jcenter  jitpack  js  karol-mazur  kotlin  kotlinconf  lambda  laravel  layers  leadership  leadtime  lein  libraries  library  libxml2  libxslt  make  makefiles  management  manager  maven-central-repository  maven-local-repository  maven  metrics  mjs  modern  module  modules  mutability  neo4j  nested  netherlands  node  nodejs  npm  open_source  opensource  ops  org-mode  package-management  package-manager  package  packages  packaging  paper  perl  php  pip  pipenv  plugins  private  process-improvement  process  productivity  programming  project-management  projectmanagement  projects  publication  pypi  python  r  references  repository  resolution  ruby  s3  s3auth  s3wagon  saas  sbt  search  security  semver  serverless  service  setuptools  share:work  shared-libraries  software-packages  software  software_development  softwaredevelopment  sourcecode  strict  swift  technology  template  test  tipsandtricks  tool  tools  tox  twine  update  updates  version  versioning  video  virtualenv  visualization  vulnerabilities  was  wastetime  web  work  yarn  youtube 

Copy this bookmark:



description:


tags: