Project no longer maintained?

[mattfysh]

It seems this project is no longer being maintained, with a high number of unanswered pull requests and issues raised. The last version v1.4.0 was published 8 months ago. I've reached out to the author via email a week ago and have not yet received a response

Does anyone know the process here is, anyone interested in forking this project and publishing under a new name?

[rbecheras]

Yes I planned to support a fork of the project.

I think about a complete re-factored project to provide

• a full templating system to allow to fully integrate the client-side (the web UI side) of the application in your standardized organization web application design or any custom one.
• custom extensions as configurable plugins, naturally managed by npm prefixed modules like custom (npm i grunt-*) and "contrib" (npm i grunt-contrib-*) grunt tasks modules are for example.

The aim will be to take advantage of its advanced personalization features while continuing to benefit of the project's progress and updates when it evolves.

[mattfysh]

@vernak2539 ?

[czardoz]

A lot of forks seem to be present (presumably because of PRs not being merged) https://github.com/rlidwka/sinopia/network

[RnbWd]

I tried a year ago - it's the most complex library written in express I've ever seen

[scic]

I would love if this project would be actively maintained again. Currently the missing/broken pull-through of scoped packages is beginning to become a blocker for me. Sadly this code is above my understanding so I can't help.

[RnbWd]

I've started using scoped packages in sinopia before it was officially implemented in npm - there's a configuration in yaml that enables pulling @name/package's. I haven't used sinopia since the scopes were implemented officially and npm was upgraded to 3.0 - so I'm not sure if the scopes pull from npm or just act locally - but effectively it can be used instead of npm as a private repo - I used it w/scoped variables - but not via npm.

[jdx]

I've got a npm server that's a bit different than sinopia, but a lot simpler that might be worth a look: https://github.com/dickeyxxx/elephant

We're using it in production at Heroku with great success! It's very fast!

[mima0815]

@rlidwka can you give us a short statement on the status of sinopia?

[RnbWd]

I just turned on my docker sinopia container for the first time in 6 months and it seems to work fine. Many of the problems posted here might be solvable by changing a few lines of code or simply making the config.yml work properly - which is honestly esoteric. But if it works.. it works. I consistently had a 10x speed improvement the entire time I used it hosted on a tiny docker server in the cloud - but I still haven't tried scoped variables since they were officially implemented. They worked fine last summer, but it requires the proper setup in the config

edit: scoped variables are working fine with me - but they're local to the sinopia. check out the configuration for my docker repo https://github.com/RnbWd/sinopia-docker

double edit: I'm using node 5.7.1 and npm 3.8.1 - but I can only get sinopia to run on 0.10 (it briefly worked with iojs) so my docker container - running sinopia in 0.10 - is probably more stable to use than if one were to just download sinopia 'vanilla' in a modern node context

[ChadKillingsworth]

Proxying scoped packages work just fine - you just have to set the config correctly (the default is wrong).

You need 2 asterisks:

packages:
  '**':
    # allow all users (including non-authenticated users) to read and
    # publish all packages
    #
    # you can specify usernames/groupnames (depending on your auth plugin)
    # and three keywords: "$all", "$anonymous", "$authenticated"
    access: $all

    # allow all known users to publish packages
    # (anyone can register by default, remember?)
    publish: $authenticated

    # if package is not available locally, proxy requests to 'npmjs' registry
    proxy: npmjs

[RnbWd]

I use this setting for scoped packages:

@/ # scoped allow_publish: $authenticated

I haven't used the "**" setting, I'm jw if there's an issue the "@/" setting when proxying npm?

[ChadKillingsworth]

The matching algorithm uses the node glob library so it's the same matching rules. A single * won't match a /, but the double ** does.

*/* works just as well if you want to have a rule for just scoped packages.

[ChadKillingsworth]

I also emailed @rlidwka about a month ago and never heard back. He has near-continuous public activity on github for the past several months which leads me to believe he is purposefully ignoring this project.

A fork, name change and license change would be in order it seems. I just don't have the time right now to maintain a package like this appropriately.

[RnbWd]

I'd volunteer to give it shot - I'm maintaining the docker container that seems to have the most downloads for this project - and I had to forked it for a minor feature so I could proxy it via ssl with minimal config. I've read every line of the code base, so I have a mental model of its structure. The foundation uses libraries that are not compatible with modern nodejs. Those sections can be rewritten, the library can be modernized, i know where it needs to change - but it's ambitious. I attempted to modernize it a year ago, but none of that's relevant now.

I need to think this over for a few days - it's not a trivial library to maintain. On Sun, Mar 13, 2016 at 7:25 PM Chad Killingsworth [email protected] wrote:

I also emailed @rlidwka https://github.com/rlidwka about a month ago and never heard back. He has near-continuous public activity on github for

[cuzzinz]

It would be amazing for this project to be forked and modernized. It is by far the fastest solution even compared to local-npm and lazy_npm.

I have compared a few different solutions and sinopia is faster by 15-30%. It is very impressive.

[dgaya]

First, thanks @rlidwka for this great software.

I already maintain a fork, https://github.com/fl4re/sinopia It is not intended to become the 'official' fork. In fact there are other forks (for example @mathieumg or @ngash) quite active too.

Our fork is internally used at my company, therefore we are going to maintain it in the future.

In this fork I have already merged some relevant PRs:

• Split travis file in install & script
• Update README to use fl4re travis badge
• Travis fix
• Change _npmUser.name to author.name for entries #352
• Update deps, make compile on Node v4 & 5 #367
• ADDED intermediate ssl certificate option #379
• Package search requires 'access' authorization #370

And we have a branch (OAuth_login) that replaces completely the registration/login workflow by Github/Google Oauth instead of plain and open user password. Beside this branch, I plan to maintain the master branch as close as possible to the original sinopia.

If anyone in the community considers our fork a good fork, I will be glad to accept PR. PRs will be accepted if:

• fixes some bug
• fixes random travis failures
• fixes jslint/jshint styling
• removes dead code
• replaces some old library by a newer one
• refactors
• add a feature and there is consensus about it (a few +1)

PRs will not be accepted if:

• modifies the original features
• adds features only needed by some individual
• brakes the travis build

[ChadKillingsworth]

@dgaya Thanks! I'll send a PR or 2 your way. Also, would you consider switching the license on your fork? I'm not sure of the implications of that, but the current license has always made me nervous.

[RnbWd]

I think I'm going to create an org - what should we call it? I don't want to use sinpopia unless @rlidwka is okay with it (love your work btw). I have some urls - like.. 'karmasync' 'event-loop' 'synctea' all .coms I'm not using at the moment (well karmasync links to a github clone and synctea is my sinopia) not that it matters but they're cheap and i don't think anyone is using them.

I want to collaborate with a group - it's not a one man project. there are other projects that are similar and it might be nice to merge with them, but none are as good as sinopia. Considering it seems to work perfectly fine for me at the moment

Feel free to use https://synctea.com for some http2 sinopia awesomeness.

I think this project deserves a working group.

edit: npm config set strict-ssl false if you decide to use synctea.com

edit: also i like what @dgaya did - but my original attempt was far more ambitious and changed lots of dependencies and code styles -- too bad I lost it - it's not worth looking for now

[dsuckau]

I really hope this project will be maintained again. We use sinopia in our company for private packages. We are kind of dependent on it now, but don't trust this repository anymore. I would contribute too....

[donny-dont]

@RnbWd maybe https://en.wikipedia.org/wiki/Sinopia would provide some inspiration.

Some things that pop out from it are

• hematite
• sinoper

[RnbWd]

Thanks - I haven't started working on anything yet but I agree with everyone that this project should be maintained. Sinopia seems to work for most things - i did notice some weirdness with @* names being pulled from npm - I just want a general consensus about what everyone is looking for, I'll need to go though the issues.

Syncing with external store (s3) is something I see mentioned constantly. I host using Docker - I can sync all the repos with an external volume that I can send to s3 or something, and I proxy with nginx. But if you're just relying on sinopia, adding hooks in the repo itself seems to be one of the most requested features, so that's one major feature that we need to decide if we want to expand it - or use external libraries for the management (like an external file watcher syncing repos)

But the critical necessity is to make sure that it will remain compatible with npm itself. It currently uses an older version of express to fake npm's backend - so if npm's api changes, then those will need to be reflected manually as express routes. But if modules from npm's repo could be used instead, then it might be possible simplify the express portion of the app without worrying about future compatibility. -- I need to create multiple test branches to see what's possible

[RnbWd]

I found a ton of resources here - awesome-npm

Here are a few modules that I think sinopia would benefit from:

• nrm - helps switch between different npm registries
• tarball-url-info from npm's repo, and I also like modules like tar-stream and tar-fs which might be a nice way to store the tars locally in sinopia's cache folder.
• npmo-auth-github - it's used for npm enterprise. Sinopia currently stores user info in a plaintext via httpasswd. IMO i think it's genius but it some people probably want a more robust login / auth method.
• ied and pnpm are alternatives to the npm-cli. The reason these might be useful has to do with their use of content-addressable_storage:
• abstract-blob-store has a rich ecosystem with hooks for leveldb, s3, google-cloud-storage, and it also works with distributed systems. If we really want to really ambitious - we could create an (optional) distributed network of npm modules using hyperdrive - which powers dat. It's a pretty cool system, they actually created a dat-npm repo that clones the entire npm registry just as an example project. It could also be used to sync sinopia registries between work / home - different cloud servers - across companies, different teams, etc. Right now everything is just stored in the local filesystem

food for thought :satisfied:

[cuzzinz]

This line stood out on the wiki for me:

To make the faces in the final fresco, Cennini recommended that the artist first paint them with an undercoat of brownish green, called a verdaccio [...] then used a fine brush and sinopia to paint the lines under the eyes, around the nose, the eyebrows, the mouth and the shading under the upper lip.

verdaccio - a green color popular in late medieval Italy for fresco painting

Since it will be a fork, follow the subject the orig project used but a new "color." .... verdaccio

Just my 2 cents

P.S. I will definitely be testing out whatever fork is created. I am using it to help eliminate the need to locally cache any modules on a jenkins slave that is building via a docker container. Smaller footprint.

[jdx]

@RnbWd if you look at my project it does S3 syncing much better.

[RnbWd]

I'll definitely check it out - I haven't started working on anything yet. If the startup I was working at last year didn't dissolve I'd have started a fork 6 months ago - but I was able to brainstorm quite a bit - and the iojs fork / es6 features made me hesitant to start any ambitious projects On Tue, Apr 5, 2016 at 10:49 AM Jeff Dickey [email protected] wrote:

@RnbWd https://github.com/RnbWd if you look at my project https://github.com/dickeyxxx/elephant it does S3 syncing much better. We use it in production at Heroku and it handles 1000 RPM beautifully.

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/rlidwka/sinopia/issues/376#issuecomment-205917410

[jmwilkinson]

What's the status on this? Is someone going to create an org called "verdaccio" and fork sinopia?

I will do it if I have to. I have just about 0 time to maintain it, though, so everyone here who is interested would have to help contribute, and hopefully shift the community over. To that end, a primary objective would be no api breaks.

If no one has taken the initiative by Monday, I'll go ahead and make it then.

[RnbWd]

I can't get mine to work anymore..

[trentearl]

This project is important to me and my company, I have created the organization: verdaccio

And forked the repo https://github.com/verdaccio/sinopia

I've added @RnbWd and happy to add others well.

I look forward to seeing this project continue to grow.

[trentearl]

Renamed to: https://github.com/verdaccio/verdaccio

[cuzzinz]

Not a real issue per se but definitely should start going through the code and replace sinopia with verdaccio. I will not be using this project for a while as things have changed gears from me but I will definitely be following it and will contribute any way I can.

:-D glad someone used the name I posted.