Provide official nuget package

Think CEF could benefit from a new feature or capability? Discuss CEF feature requests here.

Provide official nuget package

Postby sjoerd222888 » Thu Jul 30, 2015 8:07 am

This request is about providing an official .NET nuget package of CEF.

Currently there exists a CEF package used by CefSharp: cef.redist (see: https://www.nuget.org/packages/cef.redist/). This package is maintained on behalf of the CEF authors by the CefSharp project.

Also for CefGlue there do exist some unofficial packages: (see: https://www.nuget.org/packages/Unofficial.Cef/)

At CefGlue we are discussing options for nuget package to be used by CefGlue (see: https://bitbucket.org/xilium/xilium.cefglue/issues/61/make-nuget-packages). There are many aspects to be covered e.g. architecture (x86 vs. x64) and platform (Windows, Linux, OS X). At the end it boils down that an official CEFpackage would be of much help. This would also be good for the CefSharp project I think.
sjoerd222888
Techie
 
Posts: 15
Joined: Thu Jun 04, 2015 9:02 am

Re: Provide official nuget package

Postby fddima » Thu Jul 30, 2015 11:31 am

I'm try to summarize some important notes and questions from issue linked above:

Little introduction
Generally i'm propose move discussion to ceforum, 'cause i'm want:
1. Get little more community-driven "solution"
2. Little more for "official" status
It is important 'cause it is not only about technical questions, but also social: anyone can publish package on nuget feed - it is cool and handy, but in same time - developer will trust only to other developer (maintainer / group of maintainers). When developer see same product which published by different peoples, it is ask for self - what is it? How it is differs from another version / etc.

1. Versioning CEF NuGet Packages (proposition)
NuGet package versions is looks like semver, but packages can declare or do not declare semver compatibility. semver did not very good cover cef, so my proposition was:

MAJOR = Chromium major version. I.e. it is not 3. It is something like 40. CEF era (major version = 3) we can include in package name.
MINOR = Should be calculated from API hash.
PATCH = Increments on every new build, if API hash is not changed.

This means, that:
43.0.0 - first build from some branch (release or trunk)
43.0.1 - first bug-fix release, but it is provide same ABI (i.e. API hash for this release same as 43.0.0).
43.1.0 - some release from same branch, which can break ABI compatibility (i.e. API hash for this release are differs from 43.0.1)
... etc

Why this kind versioning is needed?
It is 'cause package used for distribute CEF binaries as project dependency.
It is allow to us define dependencies between package including compatible versions.
For example, concrete CefGlue package can define dependency to CEF binary package as [43.0]. This means that 43.0.0, 43.0.1, 43.0.2 is valid dependencies, and them can be updated, but not 43.1. Newer CefGlue version package can define other dependencies. Etc.
Note: that current NuGet 3.0 can't define conditional dependencies as we want, so we will not use this mechanism now. But it is easy for human understanding and machine understanding.

2. Provide packages for every platform
It will be very good to provide builds for Windows, Linux and OSX. Also x64 and x86 (when available).
Now easiest way to do it, it is get packages from http://cefbuilds.com.

3. Automation for NuGet publishing
To perform automatically publishing packages into nuget, we need able to acquire packages from cefbuilds.com. But to acquire packages we need assistance from cefbuilds.com (automatic monitoring of updates, and automatic binary downloading).

Packages & Content
Generally nuget packages can be used within C++ projects. So, as i'm understand, package can contains headers / etc.
In this topic we speak only about redistributables - i.e. just binaries. I'm think that we should be aimed now only binaries. I.e no cefclient, no other stuff, no debug build.

Package Naming
NuGet used mainly by .NET projects, and created for them.

Only one package name convention is:
Package Id Conventions
Namespace-like names: Package IDs should follow a pattern similar to namespaces in .NET. For example, Ninject.Mvc3 instead of Ninject-Mvc3.

Sample Packages: Use the ".Sample" suffix for a package that provides sample code for your package. This is useful for helping others get started. For example, if your package name is Clay, then a sample of how to use clay would be Clay.Sample. Also, within the content folder, arrange your samples within a root /Samples/PackageID folder structure. For example, the Clay.Sample package would have a folder /Samples/Clay.


I'm think that good names will be:
ChromiumEmbedded.Redist - there is meta-project. Now treat just as reserved name.
ChromiumEmbedded.Redist.Windows.x86
ChromiumEmbedded.Redist.Windows.x64
ChromiumEmbedded.Redist.Linux.x86
ChromiumEmbedded.Redist.Linux.x64
ChromiumEmbedded.Redist.OSX.x64
ChromiumEmbedded - name reserved for "official" .NET wrapper (i'm hope in one day it will be published). :)

Futures
Provide official in-time CEF builds (at least for windows). cefbuilds.com is great, but looks last time (year?) it is provide builds "lazily". Gap in 2-3 weeks is very high, - i'm not once make private build. And looks that i'm not alone.
fddima
Master
 
Posts: 788
Joined: Tue Dec 07, 2010 6:10 am

Re: Provide official nuget package

Postby magreenblatt » Thu Jul 30, 2015 5:18 pm

Does creation of a nuget package have dependencies on other tools or can it be done with a stand-alone python script? Do nuget packages need to be uploaded to the nuget website or is it sufficient to provide the packages for download via cefbuilds.com?
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: Provide official nuget package

Postby fddima » Thu Jul 30, 2015 5:28 pm

magreenblatt wrote:Does creation of a nuget package have dependencies on other tools or can it be done with a stand-alone python script? Do nuget packages need to be uploaded to the nuget website or is it sufficient to provide the packages for download via cefbuilds.com?

It is can be done with python script + nuget command line tool (requires .net or mono).
Nuget packages should be uploaded / pushed into nuget feed (nuget.org) or can be hosted on own feed, but it is requires server (asp.net).
fddima
Master
 
Posts: 788
Joined: Tue Dec 07, 2010 6:10 am

Re: Provide official nuget package

Postby amaitland » Thu Jul 30, 2015 5:38 pm

fddima wrote:NuGet package versions is looks like semver, but packages can declare or do not declare semver compatibility. semver did not very good cover cef, so my proposition was:


I think you'll likely add another layer of confusion going with a custom naming scheme here. What exactly is the problem with versioning packages after their `cef` versions?

The latest version of `cef.redist` is 3.2272.32, which works just fine.
https://www.nuget.org/packages/cef.redist.x86/

magreenblatt wrote:Does creation of a nuget package have dependencies on other tools or can it be done with a stand-alone python script? Do nuget packages need to be uploaded to the nuget website or is it sufficient to provide the packages for download via cefbuilds.com?


Requires `nuget.exe` to generate a package from a `.nuspec` file which outlines the package dependencies and layout. You could use a python script to automate the process, including the download of nuget.exe, we do something similar with powershell to generate packages for CefSharp. For the packages to be useful they really need to get pushed to nuget.org. Again this can be automated using nuget.exe, just need to provide an API key to authenticate.

As you cannot delete old packages, we'd have to be careful flooding nuget with releases, and likely only push official release packages. To get around this I'd suggest pushing to MyGet.org where you can completely control which packages are retained and manually push the official ones to Nuget.org (You can do this with a click of a button on the MyGet.org website). We effectively do this for releases of CefSharp, they build server pushes packages to MyGet.org, once they're verified manually, a couple of mouse clicks and they're published to Nuget.org.

Happy to move CefSharp over to a common set of packages, so if there's anything I can do to help let me know.
Maintainer of the CefSharp project.
amaitland
Virtuoso
 
Posts: 1290
Joined: Wed Jan 14, 2015 2:35 am

Re: Provide official nuget package

Postby magreenblatt » Thu Jul 30, 2015 5:44 pm

fddima wrote:
magreenblatt wrote:Does creation of a nuget package have dependencies on other tools or can it be done with a stand-alone python script? Do nuget packages need to be uploaded to the nuget website or is it sufficient to provide the packages for download via cefbuilds.com?

It is can be done with python script + nuget command line tool (requires .net or mono).
Nuget packages should be uploaded / pushed into nuget feed (nuget.org) or can be hosted on own feed, but it is requires server (asp.net).

That doesn't sound like something I'd want to manage as part of the core CEF deliverables. However, I encourage the CefGlue/CefSharp devs to collaborate on it if it saves them headache and I can approach Adobe to see if they'd be interested in hosting it. Other than building on cefbuilds.com what would "official" branding entail?
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: Provide official nuget package

Postby fddima » Thu Jul 30, 2015 5:58 pm

magreenblatt wrote:That doesn't sound like something I'd want to manage as part of the core CEF deliverables. However, I encourage the CefGlue/CefSharp devs to collaborate on it if it saves them headache and I can approach Adobe to see if they'd be interested in hosting it. Other than building on cefbuilds.com what would "official" branding entail?

1. It is okay to start from something small, and technical implementation is our part. I.e. now we (I'm or topic starter prepare scripts required to prepare package from existing binary distribution packages). Any required automation is also ours.

2. Make repository with source of this automation. It should be reusable a bit for private builds and private nuget feeds.

So official part is: register chromiumembedded team on nuget.org. Add responsive persons / rights. Only them can push packages.

Finally: when we found acceptable server for this small automation - it can do it automatically.
fddima
Master
 
Posts: 788
Joined: Tue Dec 07, 2010 6:10 am

Re: Provide official nuget package

Postby magreenblatt » Thu Jul 30, 2015 6:03 pm

fddima wrote:
magreenblatt wrote:That doesn't sound like something I'd want to manage as part of the core CEF deliverables. However, I encourage the CefGlue/CefSharp devs to collaborate on it if it saves them headache and I can approach Adobe to see if they'd be interested in hosting it. Other than building on cefbuilds.com what would "official" branding entail?

1. It is okay to start from something small, and technical implementation is our part. I.e. now we (I'm or topic starter prepare scripts required to prepare package from existing binary distribution packages). Any required automation is also ours.

2. Make repository with source of this automation. It should be reusable a bit for private builds and private nuget feeds.

So official part is: register chromiumembedded team on nuget.org. Add responsive persons / rights. Only them can push packages.

Finally: when we found acceptable server for this small automation - it can do it automatically.

Sounds reasonable to me. Is nuget a free service or are there likely to be fees with many files and/or collaborators?
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: Provide official nuget package

Postby fddima » Thu Jul 30, 2015 6:23 pm

magreenblatt wrote:Sounds reasonable to me. Is nuget a free service or are there likely to be fees with many files and/or collaborators?

Nuget is:
- free and open-source package manager (mainly for .net projects)
- has implepentation of nuget server feed
- shipped with visual studio
- nuget.org is free for use and publishers

PS: But may be have sense ask nuget.org about planned store size.
fddima
Master
 
Posts: 788
Joined: Tue Dec 07, 2010 6:10 am


Return to Feature Request Forum

Who is online

Users browsing this forum: No registered users and 16 guests