Code Monkey home page Code Monkey logo

packages's Introduction

Nim packages Build Status

This is a central listing of all packages for Nimble, a package manager for the Nim programming language.

An overview of all packages is available at https://nimble.directory.

NOTE: The packages listed here are not peer-reviewed or otherwise screened. We try to keep the list up-to-date but we cannot guarantee quality or maturity of the packages.

Adding your own package

To add your own package, fork this repository, edit packages.json and make a pull request.

Packages.json is a simple array of objects. Each package object should have the following fields (unless the field is marked as optional):

  • name - The name of the package, this should match the name in the package's nimble file.
  • url - The url from which to retrieve the package.
  • method - The method that should be used to retrieve this package. Currently "git" and "hg" is supported.
  • tags - A list of tags describing this package.
  • description - A description of this package.
  • license - The license of the source code in the package.
  • web - An optional URL for humans to read additional information about the package.
  • doc - An optional URL for humans to read the package HTML documentation

Requirements

While we really appreciate your contribution, please follow the requirements: other developers will rely on your package. Non-compliant packages might be removed with no warning.

  • The URL should work, a .nimble file should be present and the package should be installable
  • The package should build correctly with the latest Nim release
  • The package should not contain files without a license or in breach of 3rd parties licensing
  • Non-mature packages should be flagged as such by opening an issue here with a good explanation on how they are non-mature, especially if they perform security-critical tasks (e.g. encryption)
  • If a vulnerability is found, make a patch release against the latest stable release (or more) that fixes the issue without introducing any other change.
  • Tiny libraries should be avoided where possible
  • Avoid having many dependencies. Use "when defined(...)" to enable optional features.
  • If abandoning a package, please tag it as "abandoned"
  • The package name should be unique and specific. Avoid overly generic names e.g. "math", "http"
  • Provide a contact email address.
  • Optionally try to support older Nim releases (6 months to 1 year)
  • Optionally GPG-sign your releases
  • Optionally follow SemVer 2

Your packages may be removed if the url stops working. It goes without saying that your pull request will not be accepted unless you fill out all of the above required fields correctly, the package that url points to must also contain a .nimble file, or else it will be rejected.

The requirements might change in future.

Releasing a new package version

The version number in the directory is derived from git tags (not the version field in the .nimble script). To release a new version of a package, follow the instructions from the Nimble readme:

  • Increment the version in your .nimble file.
  • Commit your changes.
  • Tag your release, by for example running git tag v0.2.0.
  • Push your tags and commits.

Renaming packages

To rename a package you will need to add a new entry for your package. Simply perform the following steps:

  • Duplicate your package's current entry.
  • Remove every field in one of the entries apart from the name field.
  • Add an alias field to that entry.
  • Change the name in the other package entry.

For example:

...
  {
    "name": "myoldname",
    "alias": "mynewname"
  },
  {
    "name": "mynewname",
    "url": "...",
    "method": "git",
    ...
  },
...

License

packages's People

Contributors

andreaferretti avatar araq avatar ba0f3 avatar bung87 avatar c-blake avatar def- avatar dom96 avatar ehmry avatar ethosa avatar euantorano avatar federicoceratto avatar fowlmouth avatar genotrance avatar georgelemon avatar gradha avatar guzba avatar hamidb80 avatar jangko avatar jiro4989 avatar juancarlospaco avatar metagn avatar narimiran avatar planetis-m avatar pmunch avatar ringabout avatar thisago avatar thomastjdev avatar treeform avatar yglukhov avatar zah avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

packages's Issues

Allow uploading packages via nimrod alone

In Ruby, you can write a .gemspec file, then you can use "gem" to make a new gem, according to the information written in that .gemspec file.

This .gem file can then be pushed to a central repo, like rubygems at https://rubygems.org/.

You can see that the functionality of https://rubygems.org/ is quite limited, but it is quite sufficient for what 90% of the people will ever need.

This ability to publish .gem files in quite that way then allows other people to download and install such a gem, via:

gem install name

It would be nice if nimrod would be able to offer a similar functionality, at least the basic core idea of it - allow users to easily install nimrod-packages / nimrod-addons.

As far as I understood it, if you want to contribute to the nimrod ecosystem as a whole, you must use git. I.e. in babel.nim it has:

case pkg.downloadMethod
of "git":

And no other option.

As a user, I would like to have these features:

  • Ability to contribute to Nimrod packages without having to use git. (Perhaps it could be uploaded to some server, and then made available to github?). Right now babel is limited to git-users only, which I think is not a perfect situation.

  • Ability to easily create a nimrod package of some kind, and then publish and upload it. This is what I can do with gem, i.e.

    gem push *.gem

This command would push to the central repository, then others could install those gems easily.

Thanks for reading!

NimBorg no longer being maintained in original repo

Hi.

Over in the original repo for NimBorg, the author has mentioned this:

"Sorry chap, I'm not maintaining this repo any more. I'll take it down eventually so that people don't get confused. Note that some core nim devs have forked it, and perhaps other people would keep maintaining it."

micklat/NimBorg#5 (comment)

@dom96 - look into that please?

eg, changing packages json file to point to an actively maintained version.

Cannot install nim-sndfile

$ nimble install nim-sndfile --verbose
    Reading official package list
Downloading https://github.com/julienaubert/nim-sndfile using git
     Error: nim-sndfile is an invalid package name: cannot contain '-'

Tag naming / checking

Having just started adding my package to the package list, I was looking at the existing tags to see which were most appropriate. I found a lot of duplication. A few examples from the start of the alphabet:

  • "2d", "2D"
  • "authentication", "authenticator"
  • "algorithm", "algorithms"
  • "app", "application"
  • "benchmark", "benchmarking"
  • "bind", "binding", "bindings"
  • "Bloom", "Bloom filter"

The list goes on (and even includes "Nim", "nim" and "nimrod"!)...

If these tags are ever selected as the means of trying to search/filter packages, it's going to be very hard to actually find anything useful I suspect.

Clarify flagging procedure

The readme says "Non-mature packages should be flagged as such". This sounds a good idea, but I think the odds of it being done are very low if it's not suggested how to do this. I recommend changing the wording to "Non-mature packages should be flagged as such by ..."

Small change, but I imagine that would make a big difference if you want people to actually do that.

Package name scheme

Some libraries have names of the scheme nim-$library while most are just $library. This is annoying when installing a package and you have to try out both. Could we just rename all nim-$library packages?

Handling deleted packages

--- forwarded from FedericoCeratto/nim-package-directory#26 ---
--- original author: https://github.com/samdmarshall ---

today i was trying to find a package for a personal project, and came across the htmlview package. this package seems to have been deleted by the author, and never updated in the index as to have it removed entirely or redirected to the new repo. On the individual package page on https://nimble.directory/pkg/... there seems to be no way to report a problem with said package.

  • If the package doesn't have a public visible repo/source then there should be a link to create a new PR to remove the package from package index. that process should be able to be 100% automated/scripted.
  • If the package does have a public visible repo/source then there should be either a link to create a new issue on the package repo (if using github or another similar SCM system) or a mailing address for the author or to the package's mailing-list to correspond about the problem. (this may require some changes to the submission guidelines regarding new and existing packages so that non-github hosted packages provide some way of contacting the package author).

To mitigate similar future issues, perhaps a scheduled job should be added the package index CI system to validate that package sources aren't 404'ing in addition to validating that any new packages added are valid JSON or whatever.

/cc @dom96 as you originally created the package index and since it's now part of the language org, i assume you have some say in how package validation happens and if it is part of a nightly CI job or something.

All the packages no longer availabe on the provided url

This is the list of packages that are not accessible on the provided url with the git method

glfw
ao
csv2json
lapp <- unable to get local issuer certificate
blimp <- unable to get local issuer certificate
RingBuffer <- change to http?
teafiles <- change to http?
emmy <- change to http?
BN
mc_events
nimetry
algebra
nim-nmap
htmlview

Orient package is incorrect

See https://github.com/philip-wernersbach/nim-orient - the code is in the prerelease branch which is NOT the default, also it's not specified in Nimble (can we even specify a branch in packages.json? If so, I'll make a PR to fix this one).

Running nimble install orient you'll get:

~/P/n/pkgraph ❯❯❯ nimble install orient
Downloading https://github.com/philip-wernersbach/nim-orient using git
       Tip: 1 messages have been suppressed, use --verbose to show them.
     Error: Specified directory (/tmp/nimble_5457/githubcom_philipwernersbachnimorient) does not contain a .nimble file.

P.S.: Found when working with my pkgraph "project".

Empty tags

I'm working on an application that uses the packages list (packages.json) and I've found an issue (i think).
The following packages have an empty tag:

{"name":"htsparse","url":"https://github.com/haxscramper/htsparse","method":"git","tags":["library","wrapper","parser",""],...}
{"name":"syllables","url":"https://github.com/tonogram/nim-syllables","method":"git","tags":["library","language","syllable","syllables",""],...}
{"name":"drawim","url":"https://github.com/GabrielLasso/drawim","method":"git","tags":["draw","drawing","gamedev",""],...}
{"name":"scinim","url":"https://github.com/SciNim/scinim","method":"git","tags":["scinim",""],...}
{"name":"tmpnim","url":"https://github.com/ment1na/tmpnim","method":"git","tags":["library","tmpfs","ramdisk","tempfile","linux",""],...}

This isn't a critic issue but I think package_scanner.nim should check that.

[Proposal] Put each nimble package in its own file

Proposal

Put each nimble package in its own file/directory, or let each user create a subdirectory for themselves and put each package into one file.

Benefits

  • User only has to add a file to the repo instead of editing one big file. Multiple users can add packages without conflicts
  • Parser won't eventually be overwhelmed by packages (since Nim and nimble will be super popular one day!)
  • Better git history
  • If each user has their own directory, packages can be found easily by the same user (not that it isn't easy already with nimble search, but just browsing the github repo could be a fun discovery)

Downsides

  • Lots of files. But git can handle it.
  • Higher code complexity. Must write recursive directory walker and gather packages.

So what do you think? It's just an idea, but maybe it'll be of use?

Cannot get the correct version of my package

Yesterday I published my package to nimble, this morning I'm trying to install it from a project, but the wrong version is getting fetched.

nimbleinstall

In my nimble file I have

requires "raytracingalgorithm == 2.1.0"

What am i doing wrong?
Thanks

Require Release Tags

The Problem

There are a ton of packages on nimble.directory that have no releases. These packages are completely and totally unusable for any project that takes itself seriously. Without releases, there is no way for me to confirm that all users of my own packages have the correct version of my package's dependencies.

The Solution

Require all Nimble packages to have at least one release tag before they are accepted into the package list.

In addition, if I were to have it my way (though the problem may be so bad at this point that doing this would be self-destructive), any package currently in the list that doesn't have release tags should be removed until they have at least one release tag.

this packages list annoying

  • This list doesn't solve any problem.
  • Go lives a happy live without this list.
  • https://godoc.org/
  • waiting for CI to pass is annoying
  • waiting for someone to merge the PR maybe is annoying
  • dealing with broken CI is even more annoying (#1011)

Possible Solution

Make this repository obsolete.

Implement a central repository for packages

Hello.
This package list is very basic and after some time it will be unmaintenable if the ecosystem grows bigger.
I can implement a REST API for storing and retrieving nim packages in my free time if you are interested.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.