►
From YouTube: Chocolatey Overview - Package Team
Description
An overview and demo of the Chocolatey package management system
A
I'll
just
give
like
30
second
background
of
myself,
but
I
came
up
through
traditional
IT
on
the
windows
side,
but
I've
also
heavy
and
automation
on
the
window
side
for
my
entire
career,
but
I've
also
maintained
a
lamp
stack
for
my
own
business
servers
and
blogs,
so
I've
been
dangerous
enough
with
Linux
and
then
in
my
last
job,
I
ran
a
team
that
was
kind
of
fully
50/50,
Linux
and
Windows,
mainly
software
deployment,
automation
in
the
space
of
creating
automation,
templates
and
that
kind
of
thing.
So
I
was
just
going
to
give
you
guys.
A
B
D
A
So
I'll
generally
assume
that
everyone's
Linux
familiar
in
Linux
background.
If
and
at
any
point,
if
I
start
saying
stuff
that
you're
like
this
is
dull,
I
knew
this
like
ten
years
ago.
Please
speak
up
and
will
accelerate
I'm
gonna,
actually
cheat
and
use
some
of
the
plural
site
course
slides,
which,
in
our
current
context,
is
an
acceptable
use.
I'm
just
going
to
Nick
through
some
of
them.
Try
to
give
you
some
of
those
connections
and
see
where,
where
we
can
go
from
there,
so
just.
A
A
B
A
And
and
of
course,
I
think
and
get
labs
current
offerings.
What
I'm
talking
about
here
would
be
the
responsibility,
the
customer
at
this
point,
unless
we
get
so
mature
that
we're
doing
like
automated
deployment
to
dotnet
or
to
Windows
in
some
form.
So
basically
there's
a
new
spec
file,
basic
file
specification
for
creating
a
new
package.
A
You
create
that
package.
When
you
create
it,
you
can
target
multiple
dotnet
C
realizations,
but
when
you
do
that,
you
get
a
compiled
assembly
for
each
target.
So
if
you're
targeting
net
three
dotnet
for
dotnet
core
2,
then
you
end
up
with
a
compiled
object
for
each
one.
They
all
get
included,
because
the
process
of
installing
is
very
simplistic.
A
You
then
load
that
up
to
a
potentially
to
a
store
of
some
type
of
feed
base
or
using
the
API
very
standard
API
s,
and
then,
when
the
client
wants
to
use
this,
they
use
nougat
XE,
which
is
the
client
you
don't
really
need
to
install
it.
It
can
run
just
as
a
bear
eggsy
and
then
that
on
an
installs,
the
dotnet
assemblies,
if
you
run
from
within
visual
studio
code,
we'll
touch
on
this.
A
A
little
bit
later,
then
there
is
the
possibility
of
doing
some
additional
logic
to
wire
it
up
and
if
you
run
outside
of
visual
studio,
you
just
run
playing
nougat
eggsy,
then
you're,
basically
getting
a
file
extraction
to
a
location
of
your
choice
that
can
potentially
target
whatever
serialization
you're
you're
going
for
so
it's
automation,
ready,
middleware,
handles
middleware
and
toolkits
it's
for
dev
and
prod
in
terms
of
dependency
resolution,
and
you
can
create
the
packaging.
It's
mainly
focused
around
server
applications
compared
to
you
can
use
it
for
client
apps.
A
But
you
know:
there's
no
GUI
experience
for
individuals
who
are
trying
to
install
software
on
their
target
system,
so
you
might
use
it
in
background.
It
does
not
have
an
interactive
UI,
it
does
not
handle
issues
of
permissions
on
end-user
type
devices
and
it
does
not
handle
user
configuration
of
the
app
and
it
doesn't
handle
non
dotnet
installs.
This
original
information
is
target
around
a
lot
of
administrators
who
are
making
packaging
that
hits
a
desktop
endpoints,
so
you'll,
that's
kind
of
reflected
in
some
of
the
things
that
are
drawn
out
here.
A
You
guys
are
already
familiar
with
feed
feeds
and
authenticated
feeds
from
other
systems.
I
just
want
to
point
out
that
in
the
case
of
nougat,
it
can
treat
a
file,
a
folder
full
of
files,
just
like
a
repo.
So
if
I
have
five
hundred
dependencies,
I
could
throw
them
all
in
one
folder,
assuming
that
they
don't
have
any
overlapping
names
and
I
could
say
you
know,
nougat
I
need
this
installed
and
here's
another
source
location
for
dependencies,
and
it
would
traverse
that
as
if
it
was
a
fully
functional
feed.
A
This
can
make
certain
deployment
scenarios
really
cool
like
products
like
octopus
that
are
deploying
dotnet.
Instead
of
having
to
have
a
feed
set
up,
you
could
theoretically
just
bring
a
bulk
load
of
files.
Anyone
doing
infrastructure
automation
would
also
be
tempted
to
do
that.
So
you
don't
have
to
set
up
a
feed
or
they
don't
have
to
have
external
dependencies
on
the
Internet,
especially
for
production
scaling.
A
A
Okay,
so
we
already
saw
that
setup
once
just
a
minute
ago.
Let's
add
in
the
chocolatey
bit
so
chocolate
he's
going
to
take
and
extend
this
to
be
able
to
do
operating
system
packages.
So
here's
a
simple
way
to
think
about
it.
What
if
I
used
NPM
to
install
browsers
on
servers
or
install
patches
on
servers
or
some
other
operating
system?
A
What,
if
I,
could
kind
of
shoehorn
it
into
providing
yum
the
type
capabilities
that
we
typically
use
a
completely
different
package
manager
for-
and
this
is
basically
all
chocolate
he
has
done-
is
we
go
ahead
and
we
hijack
an
existing
system,
especially
the
feed
system,
feed
API?
Is
we
don't
have
to
write
all
that
special
and
we
use
it
to
do
operating
system
package
with
just
a
few
simple
tweaks
or
what
started
out
as
a
few
simple
tweaks.
So
with
chocolaty
we
have
a
C
pack
utility,
which
is
very
similar
to
the
nougat
packing
utility.
A
We
create
a
standard
new
package
file
which,
by
the
way,
if
you're
not
already
familiar
with
just
a
zip
file,
if
you
rename
it
to
zip
and
double-click
it
or
unzip
it
with
the
utility
it'll
just
unzip.
It's
based
on
the
standard
that
Microsoft
and
a
few
other
places
tried
to
make
as
a
standard,
encapsulating
format
for
all
kinds
of
file.
Things
didn't
take
off,
but
it's
basically
based
on
the
zip
format.
So
then
you
upload
to
chocolaty
org
instead
of
nougat
org,
then
in
the
chocolaty
client.
A
Development
or
a
production
environment
I
can
now
install
operate
and
packages
so
that
install
can
now
be
a
zip
and
msi
and
msu
is
set
up
XE.
So
all
these
other
set
up
types
can
now
be
either
encapsulated
into
my
new
package
or
as
well
see
with
chocolaty
they're,
usually
external
and
downloaded
and
checks
them
dynamically,
and
then
that
makes
it
so
that
the
packages
and
the
job
of
chocolaty
dot
org
is
much
simpler.
A
So
with
chocolaty
when
we
chocolate
okay,
so
this
is
your
Pat,
your
new
get
engine,
and
if
we
chocolate
eyes
this,
we
basically
are
doing
you
know
very
similar
work.
We
now
have
an
installable
client
for
chocolaty.
Also
this
hasn't
worked
out
so
well,
which
we'll
talk
about
in
a
bit
but
windows
as
of
PowerShell
five
got
a
true
package
manager,
but
it's
a
meta
package
manager.
A
So
if
you
can
imagine
that
could
manage
young
packages
and
NPM
packages
and
it
would
just
all
consider
those
providers
and
consumers
of
the
overall
concept
of
delivering
content
through
packages,
that's
what
PowerShell
built
in
package
management
is,
and
it's
becoming
Windows
platform
package
management
really,
but
basically
there's
a
whole
bunch
of
packaging
formats
and
Windows
and
other
operating
systems
so
going
forward.
Anyone
in
the
community
can
actually
develop
providers
to
the
package
manager,
that's
built
into
PowerShell,
no
matter
what
the
target
is
Linux
or
Windows,
and
they
can
start
providing
packaging
through
that.
A
So
the
big
secret
here
is,
if
there's
certain
powershell
files
in
a
certain
folder
inside
the
new
package,
chocolate
it
goes.
There's
my
target
grab
chocolaty
install
and
run
it
it
also.
There
can
be
there
can
be
a
chocolaty
uninstall,
and
it
knows
that
if
I
run
a
chocolaty
uninstall
command
go
to
the
now.
The
cached
repo
of
Pat
are
cached
folders
of
packages
and
see,
if
there's
an
uninstall
and
run
it.
A
If
not,
it's
got
a
whole
bunch
of
automatic
uninstall
capabilities
where,
during
the
install
it
does
a
heuristic
detection
of
whether
it's
an
MSI.
It's
a
set
up,
eggsy
and
there's
about
5,000
kinds
of
setup
eggs
either
can
be
on
windows
as
to
what
bill
to
set
up
and
it's
able
to
fingerprint
which
one
it
is
and
know
the
silent,
unjust,
all
commands.
A
So
there's
also
automatic
uninstalled
capability,
then,
with
chocolaty
a
lot
of
the
packages,
it's
actually
goes
and
fetches
the
files
and
does
a
checksum
on
them
to
make
sure
that
they're
exactly
what
would
the
package
was
originally
designed
and
tested
around,
and
then
it
copies
it
over
that
setup
file
and
runs
it.
You
should
also
be
aware
that
chocolaty
org
does
a
lot
of
virus
scanning
on
everything
that
is
uploaded
to
it
submits
to
virus
total,
as
well
as
any
of
these
HTTP
references.
A
A
There's
still
things
it
doesn't
do
for
packaging,
so
it
is
really
more
of
a
yum
type.
Packager
does
not
replace
something
like
msi.
It
doesn't
really
focus
on
users
running
installs,
so
whatever
you
package
with
that,
they
have
to
be
completely
silent.
Even
if
it
is
a
user
install,
it's
not
going
to
pop
up
a
dialog
where
user
picks,
which
options
or
types
in
data.
A
A
And
all
feed
capabilities
are
directly
inherited
from
nougats,
so
it
doesn't
have
any
additions
to
the
feed
capabilities
that
that
feed
that
serves
chocolaty
is
identical
to
a
feed
that
serves
nougat.
So
anything
like
you
go
to
Nexus
repo,
they
don't
have
anything
called
a
chocolaty
feed
and
that's
because
you
just
create
a
new
get
feed
and
chocolaty
could
be
completely
serviced
by.
A
Basically,
I'm
just
gonna
populate
this.
This
is
comparing
the
full
chocolaty
client
which
can
run
in
CMD
cly.
So
it's
not
powershell
tethered
and
it
is,
you
can
either
do
chocolaty
space
install
or
see
instant,
so
there's
cnc,
Nancy
lists,
so
there's
a
bunch
of
aliases
built
in
as
well
the
WM
windows
management
package
provider,
which
started
with
powershell
5
and
it's
continuing
into
powershell
core.
It
is
there's
a
provider
so
that
you
can
do
chocolaty
packages
and
this
really
hasn't
come
together.
At
a
certain
point,
a
Microsoft
employee
started
the
provider.
A
They
were
done
with
it.
The
chocolaty
community
said
well,
we
might
maintain
it,
but
then
they've
been
not
maintaining
it
because
they
can't
simply
install
the
whole
chocolaty
client
just
have
a
stub
that
references
it.
So
then
they
have
to
have
two
code
bases
the.net
assembly
that
does
virtually
everything
chocolate
he
does
and
the
chocolaty
client
so
they've
been
hesitant
to
own
it.
So
consequently
you
basically
have
to
install
the
chocolaty
client
as
opposed
to
using
the
built
in
package
provider,
which
would
make
this
a
lot
simpler.
A
I'm
not
going
to
go
through
that,
but
I
just
want
to
show
you
a
quick
demo
of
the
overall
Windows
package
management
which
might
be
of
interest
for
your
team
in
the
long
run.
But
let's
do
find
package
provider,
so
it's
got
a
provider
and
consumer
model
so
on
powershell
core.
These
are
the
package
providers
that
I
could
install,
so
I
can
stall,
PowerShell
get
which
lets
me
get
stuff
from
the
PowerShell
gallery.
A
I
can
install
the
container
image
provider
which
lets
me
pull
down
specific
container
images
from
from
any
container
registry
and
the
Nano
server
package.
Nano
totally
did
away
with
the
normal
windows
way
of
installing
software
on
the
net
on
the
windows
platform
because
they
wanted
to
strip
down
to
a
super
micro
eyes
kernel.
So
it's
got
its
own
packaging
type
management.
That's
much
more
simple
and
you
can
only
really
manage
that
through
PowerShell.
If
I
do
get
package
provider,
I
can
see
what
ones
I
have
installed
locally.
A
So
I
can
discover
new
installable
package
managers,
which
can
be
populated
by
open
source
efforts
or
whatever,
and
then
I
can
install
those
package
managers
and
then
I
can
configure
that
resource
to
that
package
manager
specific
way
of
dealing
with
packages-
and
you
don't
have
to
be
at
Microsoft
to
extend
this
in
any
way.
Here's
the
ones
for
Windows
PowerShell.
A
So
there
are
a
lot
more
of
them,
so
there's
github
and
get
lab
as
providers
where,
basically,
you
kind
of
expose
a
script
up
on
github
or
gitlab,
and
then
you
can
use
it
as
a
package.
Within
the
package
manager,
there
is
stuff
for
office,
365,
there's
pac-man
provider,
so
there's
a
lot
of
different
providers.
This
is
not
completely
managed
by
Microsoft,
so
you
could
have
one
on
here:
that's
not
working
so
well
or
someone
lost
interest
in
maintaining
it.
A
So
chocolatey
org
is
a
free
open-source
package
repository.
So
all
it
is,
is
someone
said:
oh
I
want
to
pack
I
need
Google
Chrome
at
my
company
or
I
feel
like
doing
this,
because
I
have
enjoying
I'm
a
package
or
a
Microsoft,
Windows,
packager
and
I
enjoy
doing
it,
so
they
go
create
a
package
for
Google
Chrome.
That
becomes
the
official,
but
it's
totally
false.
So
if
they
only
test
it
in
a
100
s,
Target
or
they
didn't
do
something
quite
right-
that's
not
genericized
to
them
the
massive
target
of
Windows
base.
A
A
Okay,
so
here's
Adobe,
Acrobat,
Reader
and
I
can
find
out.
This
is
the
GUI
to
the
repo
so
like,
if
you
ever
gone
into
Nexus
repo,
the
movies
pretty
ugly,
so
one
thing
about
the
whole
windows,
community
and
packaging,
is
they
kind
of
expect
it
to
look
like
chocolaty,
org
or
nougat
org,
and
the
Microsoft
native
tool,
Pro
GATT,
which
originated
nougat
repositories,
made
sure
and
made
panes
for
their
GUI?
To
look
like
what
these
repositories
look
like
chalk.
A
These
recently
received
a
pretty
big
overhaul,
so
it
shows
you
what
files
are
inside
virus
scan
results
for
all
files
that
are
inside
and
files
that
are
pulled
down
by
the
package
release,
notes
which
the
developer
has
control
over
by
the
spec
file,
and
then
you
have
on
the
left
here
who
packaged
it.
This
is
a
guy
who
invented
chocolaty
where
the
source
is
so.
If
I
open
this
I
can
see.
Within
this
case
the
source
is
on
github
I
can
see
where
the
source
is
I
can
go
through
it.
A
I
could
make
a
copy
of
it.
I
could
curate
it
internally
and
run
it.
You
know
build
this
package
internal
in
my
company.
One
thing
I
might
want
to
do
if
I'm
pulling
it
internal
is
to
put
the
source
files
inside
the
package
rather
than
have
them
referenced
externally,
so
that
they're
not
out
on
the
internet
and
so
that
I,
if
I,
need
to
use
this
adobe
reader.
That's
in
ten
years,
the
same
old
version
I
have
a
copy
of
the
Installer
internally
and
plus
chocolate
go
to
work.
A
A
If
you're
under
50
Meg's
and
the
user
agreement
clearly
states
that
it's
OK
to
redistribute,
then
you
can
go
ahead
and
put
the
Installer
right
inside
the
new
package
and
upload
it
to
chocolaty
and
also
usually
down
here
will
be
so
an
issues
link
how
to
report
issues
licenses.
All
that
kind
of
information
is
right
here.
A
A
Don't
want
my
NPM
packages
to
be
out
on
the
internet
when
I
worked
it
in,
for
you
weren't
allowed
to
do
that,
because
if
during
production
scaling
the
NPN
public
NPM
public
repository
was
not
available
and
you're
pulling
all
your
dependencies,
you
couldn't
do
an
auto
scale
of
a
new
instance
of
your
server,
so
that
was
no
good,
so
you
had
to
in
theory,
you're
supposed
to
pull
all
dependencies
internal.
In
this
case,
we're
discussing
you
should
really
be
curating
them
to
not
simply
pulling
them
down
and
trusting
them
all
now,
of
course,
get
lab.
A
Has
the
ability
to
scan
well,
it
has
the
ability
to
scan
the
software,
so
I
guess
you
would
get
dependencies
in
here
next.
This
is
hole.
Scanning
capability
is
based
on.
Assuming
you
already
have
packages,
so
get
lab
is
a
step
better
than
that.
In
that
we
can
scan
packages,
but
also
anything
else,
that's
in
the
codebase,
so
this
is
oops
most
spun,
my
mouse
there.
A
This
is
just
showing
you
what
kind
of
install
types
you
can
encapsulate
so
chocolaty
lets.
You
encapsulate
all
the
traditional
installers
on
Windows,
but
it
also
lets
you
encapsulate
non
installs.
So
basically,
if
you
have
a
Windows
piece
of
software
that
just
drops
in
eggs
either
is
no
install
or
it's
all.
Inside
of
a
zip
chocolaty
adds
value
around
that
to
making
it
appear
like
it's
a
formal
install,
so
one
of
the
things
it
does
is,
if
you
unzip
software,
it
puts
a
stub
into
a
on
the
path
so
automatically.
A
A
This
is
from
the
PowerShell
and
DevOps
conference.
I
spoke
out
a
couple
years
ago.
Now:
here's
here's
one
of
the
big
things
that
ads
for
software
distribution
on
the
windows
side.
So
if
you
look
at
all
of
these
types
of
installs
across
the
bottom
and
then
you
look
at
all
the
possible
consumers
of
those
installs
windows,
folks
have
a
permutations
problem
11
times
8
in
this
case,
88
individual
possibilities
of
meat
having
to
figure
out
how
to
make
this
work
under
that,
and
so
that's
a
big
pain.
A
What
chocolate
he
does!
It
says:
let's
make
a
standardized
interface
at
the
package
level,
and
now
I
can
present
that
API
to
these
machines
and
I
draw
dramatically
dropped
my
permutations.
This
is
both
at
runtime
but
test
time
as
well.
If
I
can
get
a
chocolaty
package
to
run
under
octopus,
deploy
or
PowerShell,
then
I'm
pretty
99%
sure
it's
going
to
run
under
all
the
rest
of
these
and.
A
A
Yeah
then
we
get
two
repositories.
This
is
just
an
example:
I'm
just
gonna
blow
this
right
out
to
the
full-on
capability.
So
if
I
get
a
new
nougat
feed
I
can
both
I
can
curate
foss
into
it.
I
can
also
create
my
own
packages
during
CI
and
then
put
them
in
the
repo
and
use
them
during
deployment,
as
we
would
do
with
all
package
managers,
but
I
can
also
service
a
lot
of
non
manage
scenarios.
A
So
this
is
really
a
lot
about
how
feeds
work
in
the
fact
that
you
can
use
them
for
development
or
for
in
the
case
of
chocolaty
packages,
because
they
are
standalone
operating
system
packages.
You
have
a
lot
of
flexibility,
so
a
lot
of
companies
will
have.
We
just
talked
to
a
company
where
all
of
their
branch
builds.
Development
and
testing
goes
on
on
workstations
and
they
only
care
for
gitlab
once
you
upload
it
and
merge
it
into
one
of
their
three
branches,
that's
when
they
start
caring
about
CI.
A
So,
basically,
you
have
the
idea
of
a
packager
that
does
after
development
dependencies,
then
one
that
does
operating
systems,
so
chocolaty
kind
of
unifies
those
two
but
then
I
was
advocating
within
the
Windows
community
to
push
it
one
step
further,
which
is
to
also
put
your
automation
orchestration
in
there.
So,
instead
of
having
a
bunch
of
junk
tethered
to
chef
or
Packer
or
CloudFormation,
where
you
can't
reuse
it,
you
do
simple
automation.
A
Packages
like
install
I
is
usually
that
ends
up
in
this
level
here
in
some
sort
of
proprietary
mechanism
that
one
or
more
than
one
organ,
two
different
organizations.
I
pushed
that
kind
of
logic
into
packages.
So
all
the
orchestration
logic
was
run
package
run
package
run
package,
run
package
run
package,
so
even
a
bit
of
orchestration
automation,
I,
would
put
it
in
there
and
all
of
a
sudden
we
were
able
to
deploy
any
which
way
we
could
deploy
to
a
VM
on
on
on
Mac
we
could
deploy
to
native
Windows
workstations.
A
We
could
deploy
to
the
cloud
for
CI
or
the
cloud
for
a
developer
workstation
in
the
cloud.
So
what
it
did
was
it
took
one
more
step
further
and
said:
no
orchestration
automation
code
should
be
loosely
coupled
not
tightly.
Coupled
to
these
frameworks,
you
basically
choose
where
your
automation
logic
layer
would
go.
That's
a
novel
perspective.
That's
not
really
huge
in
the
windows
or
chocolaty
communities
right
now,
but
it
is
something
that
I
still
feel
strongly
about
by
not
putting
not
not
allowing
yourself
to
get
tethered
to
these
middle
folks.
A
You
actually
make
your
build
capabilities
of
that
stack,
much
more
flexible
and,
in
my
case,
one
of
the
things
that
was
a
pressure
was
they
wanted
to
do
chef,
but
they
were
doing
it
serverless
and
without
the
server
version
and
paying
for
it.
You
can't
get
all
the
data
capabilities
to
share
data
and
then
on
config
data.
Then
they
were
gonna
pay
for
it,
but
they
didn't
want
to
pay
for
every
developer
workstation,
but
we
wanted
to
use
the
exact
same
packages
to
build
developer
workstations,
as
we
did
for
everything
else.
A
A
So
that's
that's
everything
that
I
have
as
far
as
the
just
kind
of
giving
the
background,
and
hopefully
it
helps
you
place
to
that.
If
we
get
folks
who
are
doing
chocolaty,
they're
gonna
have
a
lot
of
questions
around
you
know
stuff,
like
you
know,
how
do
I
get
packages
out
of
chocolaty
org
and
put
them
inside
of
gitlab?
Oh
I
should
also
tell
you
guys
that
there
is
a
image
out
there
up.
A
This
image
here,
Linna
Turk,
mano
choco,
is
dotnet
mano
running
on
Linux,
with
some
additional
utilities
to
be
able
to
build
chocolaty
packages.
So
this
is
still
working,
though
it's
not
an
official
output
of
the
chocolaty
organization
or
anyone
else.
But
today
you
can
build
new
packages,
which
means
you
can
build
chocolaty
packages
with
manon
mono.
So
we
could
have
that
capability
without
having
to
have
native
windows,
containers
or
native
windows,
runners,
I
think
you're,
muted,
Steve.
B
A
B
Have
a
couple,
maybe
high
level
questions
so
I'm
curious
from
your
experience.
Do
you
see
people
discover
and
start
using
chocolaty
when
they
have
that
specific
need
of
dealing
with
operating
system
packages
or
or
is
it
more
well-known,
as
just
kind
of
you
know,
having
this
very
interface
and
smoother
ability
of
you
know
not
having
to
deal
with
all
the
different
like
you
know
the
11
times,
8
problem,
that's.
A
Right
right,
a
lot
of
frankly,
a
lot
of
okay,
so
there's
a
traditional
IT
and
then
the
DevOps
or
SAS
company,
probably
or
a
true
DevOps
organization,
inside
of
traditional
IT.
So
on
the
traditional
IT
side,
they
of
course
try
to
drive,
so
they
don't
have
eleven
possible.
You
know
across
the
top
or
whatever
we
had
there.
A
Four
different
mechanisms,
but
some
companies
are
do
acquisitions
and
they
can't
afford
to
you,
know,
convert
everyone
from
SCCM
to
another
traditional
IT
product
and
some
companies
have
in
for
had
SCCM
by
the
IT
department,
but
there
were
100
percent
SAS
companies.
So
all
the
SAS
development
didn't
care
about
SCCM
and
I
highly
recommended
not
to
put
it
on
SAS
stacks.
It's
designed
around
internal
development,
so
it
kind
of
depends
where
they're
coming
at
it
from
so
IT
departments
will
see
this
as
a
way
to
if
they
have
a
complex
in
a
run
environment.
A
They'll
see
it
as
a
way
to
make
that
simpler.
Unfortunately,
if
they're
like
a
100
percent
SCCM
shop,
they
are
there's
things
that
SCCM
itself
adds
value.
That
trying
to
go
onto
chocolaty
packages
might
go
a
little
bit
backwards.
The
other
pressure
to
do
it
is
there's
already
existing
packages.
There's
some
pretty
complicated
logic
in
some
of
these
packages,
because
you
think
something
like
installing
Google
Chrome
should
be
simple.
Well,
it
is,
unless
you
want
to
customize
ten
things
as
well,
so
that
config
management
piece
a
lot
of
times
get
work.
A
It's
worked
into
these
Foss
packages
on
the
developer
side,
I
think
a
lots
going
to
depend
on.
Yes,
it's
really
going
to
depend
on
what
the
developers
have
responsibility
to
do
the
automation
so
where
I
was
it
in,
for
initially
developers
did
not,
but
when
they
went
to
the
new
multi-tenant
infrastructure,
they
were
forced
to
take
on
the
burden
of
doing
their
own
automation.
So
the
same
development
team
had
to
build
the
automation
to
deploy
as
well
as
build
the
software.
So
then
that's
another
place
that
might
be
an
entry
point
where
people
are
like.
A
Okay
for
our
test
systems.
We
need
Chrome
because
we're
gonna
drive
browsers
with
you
know,
test
framework.
Do
we
sit
here
as
pure
software
devs
and
try
to
figure
out
what
all
those
crazy
infrastructure
guys
do
to
get
chrome
installed
and
configured?
Where
do
we
go
grab
this
chocolaty
package?
Oh,
you
know,
what's
gonna
happen
if
they
is
thinking
aware
of
it
at
all
so
and.
C
A
Now
in
the
Windows
community
it
was
pushed
really
hard.
You
guys
should
also
realize
there
is
a
monthly
PowerShell
call.
It's
basically
Microsoft
open
source
initiatives.
They,
those
guys,
are
super
open
source.
The
first
demos
I
saw
of
PowerShell
six
years
ago.
The
guy
was
using
VI
to
edit
his
coat
because
he
was
a
Linux
salt
from
way
back,
and
so,
when
the
PowerShell
was
not
built
to
compete
with
vbscript
and
CMD,
it
was
built
to
compete
with
bash
before
they
ever
knew
that
they
would
be
multi-platform.
A
So
all
the
comments
you
hear
early
on
at
Jeffrey's
turn
over
talking
about
it,
he's
talking
about
bash
VMS,
all
that
all
the
shells
that
they
went
and
grabbed
the
best
practices
from
they
never
dreamed
at
the
time
that
dotnet
could
go
multi-platinum
and
that
they
could
so
its
destructive
to
sit
in
those
calls
and
hear.
What's
going
on
that
community
too,
as
well,
because
it's
a
pretty
authentic
open-source
movement,
they're
cool.
B
When
it
comes
to
the
whole
multi-platform
aspect,
is
there
anything
I
mean
cuz,
I
think
at
least
we're
all
on
the
next
machines
and
I
don't
know
if
anyone
has
a
and
on
our
team
at
least
has
a
Windows
environment
set
up
when
it
comes
to
like
if
we're
building
out
a
feed
or
just
you
know
the
basic
package
management
structure.
Do
you
think
there's
any
concern
about
any
specific
scenarios
where
we
might
want
to
have
a
Windows
machine
available
to
be
able
to
test
specific
download
and
install
capabilities
I.
A
Think
so,
because
if
you're
gonna
test,
whether
it's
deploying
properly
you're
gonna
want
to
run
the
real
client,
so
nougat
eggsy
or
chocolate
clients,
if
you
put
them
into
your
test
portfolio,
you
could
use
a
server
2016
headless
vm.
You
could
spin
up
something
in
AWS
whether
has
a
GUI
or
not
for
Windows
or
in
Azure.
A
I,
probably
would
not
use
PowerShell
core
on
Mac.
To
try
to
validate
that
everything
is
happening
is
the
way
we're
doing
a
window
block
windows
box.
The
pathing
is
different
and
so
yeah,
it's
not
so
ubiquitous
that
and
then
also
developers
are.
You
would
also
potentially
want
to
validate
Visual
Studio
installs.
So
if
a
team
has
a
whole
bunch
of
new
gate
dependencies
of
their
own
that
are
just
mapped
out
in
nougat,
then
they're
gonna
potentially
want
to
run
that
on
Visual
Studio
to
install
their
own
dependencies
for
their
own
development.
A
So
you
might
also
need
to
look
at
having
Visual
Studio
running
and
can
I
talk.
Can
I
talk
to
the
feed
so
yeah
the
minimum
nougat
eggsy
Visual
Studio,
because
those
are
the
officially
supported
and
official
targets
of
nougat
just
bare
nougat,
and
then,
if
you
wanted
to
make
sure
that
you
could
have
a
chocolaty
conversation
with
customers,
you'd
probably
want
to
run
some
chocolaty
tests
as
well
and.
B
So,
like
I've
really
only
brushed
the
surface
on
a
lot
of
this,
but
my
understanding
is
that
all
of
the
different
nougat
systems
are
using
that
same
feed
API
for
the
most
part.
So
from
what
I
can
tell
as
long
as
we
can
implement
that
feed
API
properly,
we
should
be
able
to
handle
all
of
the
different
platforms
properly,
but
I
wasn't
sure
if.
A
Yep
I
would
agree,
yeah
I
would
totally
agree.
The
one
caution,
I
would
add,
is
that
and
I
think
I
don't
know
if
I
meant
where
I
mentioned
this,
but
Windows
folks
tend
to
be
more
GUI
driven,
it's
no
secret
right,
so
they
go
to
nougat,
org
and
chocolaty
org
and
they
see
a
certain
GUI
and
I.
Oh
I
know
I
gave
this
feedback
to
Nexis
recently
when
you
go
to
a
Nexus
feed,
it
looks
like
just
the
keep
a
table
of
the
attribute
data
and
it's
really
ugly
and
I,
encourage
them
and
I.
A
Think
it's
skinnable
on
Nexus
I
encourage
them
for
nougat
feed,
give
a
default
skin.
That
looks
somewhat
like
buddy
or
no
chocolate.
Does
it
enhanced
metadata
extraction
when
you
upload
to
the
feed
to
build
that
that
page
view,
but
I
encourage
them
to
put
up
put
a
pretty
GUI
on
it
so
that
it
matches
so
that
people
oh
and
a
pro
get
was
the
windows
was
the
one
that
has
a
windows
heritage
as
far
as
doing
nougat
feeds.
A
A
The
developers
are
never
gonna
be
in
here,
because
they're
not
using
it
as
a
catalog
of
what
they
want
to
install
they're,
just
gonna
push
it
up
into
the
feed
with
an
API
and
pull
it
down
at
deployment
time
with
an
API
they're,
really
never
gonna
be
in
here.
So
I
was
able
to
think
through
that
you
might
find
it.
A
A
lot
of
product
selectors
are
gonna,
get
hung
up
on
whether
there's
a
graphical
view
of
the
feed
and
whether
it
looks
like
what
they're
familiar
with,
but
that
can
be
just
a
strategic
kind
of
thing
right
that
you
think
about
and
see
see
try
to
find
out
how
customers
are
responding.
If
these
guys
are
pure
dotnet
shops,
they're
already
running
like
dotnet,
core
or
Windows
containers,
they're-
probably
not
gonna
care
a
whit
so
but
you'll
probably
start
getting
both
kinds
of
customers.
A
You
know
chewing
that
you
and
you're
gonna
be
wondering:
why
do
they
care
what
the
GUI?
What
do
we
need
a
GUI?
What
why
do
they
care
what
it
looks
like
so
yeah?
You
know
because
of
chocolaty
you'll
end
up
with
a
lot
of
like
IT
admin,
kind
of
input,
and
it
part
of
it
depends
what
the
strategy
is
with
feeds.
A
So,
like
team
team
city
which
I'm
familiar
with
had
an
internal
feed
that
would
just
feed
the
pipeline
to
out
to
CD,
you
know
to,
and
then
even
octopus
would
grab
the
package
and
have
an
internal
feed
or
just
artifact
transfer.
If
there's
no
dependencies
and
then
everybody
started
demanding
all
that
feeds
useful
to
me.
A
I
want
to
be
able
to
see
it
outside
the
product,
so
I
want
to
be
able
to
just
reference
it
as
a
feed
like
I
would
go
to
a
public
repository,
and
so
that's
another
place
where
I
don't
know
as
you're
developing
feeds
where
that
fits
into
your
decision
tree
of
well.
Do
we
do
that
or
is
the
feed
just
internal
to
CD?
You
know
to
get
lab
CD
only
and
that
kind
of
stuff,
but
as
soon
as
you
make
an
external
someone's
gonna
want
to
upload
chocolate
packages,
probably
and
happy
asking.
B
A
So
to
me,
a
feed,
sometimes
here's
an
interesting
distinction.
Why
drove
out
that
nougat?
You
can
point
it
at
a
big
big
directory.
Full
of
files
is
sometimes
the
feed
on
the
server
end
is
providing
some
sort
of
logic
of
doing
some,
something
we're
on
nougat.
It
doesn't
and
I
know
other
ones.
Don't
the
client
has
all
the
logic
for
resolving
dependencies,
so
that
would
be
an
important
distinct.
A
Just
distinctive
difference
is
and
I'm
not
sure
you
guys
might
tell
me:
hey
every
feed
we've
been
exposed
to
all
the
logics
on
the
client
for
dependency
resolution,
but
yeah.
Definitely
it's
the
same
register
any
time
you
take
an
artifact
that
I
want
to
use
for
dependencies
during
Cir
development
or
push
to
production.
To
me,
it's
the
exact
same
concept:
okay,.
C
B
The
terminology
and
I
have
one
other
question
and
then
I
mean
others
might
have
questions
too
I'm
kind
of
hogging
all
the
questions.
So
after
the
chat
it
sounds
like
nougaty
or
chocolate.
Chocolaty
is
a
wrapper
around
a
nougat.
So
if
we
implement
the
nougat
feed,
is
it
conceivable
that
you
know
building
chocolaty
on
top
like
if
we
built
chocolaty?
Would
we
be
likely
implementing
that
feed
system
as
well,
anyways
or.
A
Yeah,
you
are,
if
you
develop
a
full
nougat
feed
capability
and
you
want
to
be
able
to
do
chocolaty
on
top
of
it
and
really
it's
not
a
wrapper
around
it's.
Actually.
The
injection
within
so
in
the
in
the
when
I
do
is
chokolate
ICI
pack,
it's
going
to
do
a
standard,
nougat
C
pack
and
make
sure
that
certain
files
are
there
and
do
certain
validation.
Now
I've
got
a
standalone
nougat
artifact
that
no
nougat
repository
will
ever
know
has
chocolaty
stuff
in
it.
A
Then,
when
it
gets
to
the
client,
which
is
also
owned
by
chocolaty,
it's
smart
enough
to
go
after
we
extract
this
package,
whoa,
hey,
there's
a
chocolaty
install!
Let's
run
that
puppy
and
then
they've
got
a
whole
bunch
of
they'll
built
a
whole
library
of
their
own
extension
functions
within
that
powershell
chocolaty
install
that
you
can
use
to
make
things
easier
to
validate
things
to
make
sure
things
get
in
the
right
places.
So
really
it's
a
it's,
not
a
wrapper
around
nougat.
A
B
D
As
far
as
ants
dude,
if
we
released
a
new
get
feedback,
we
get
chocolaty
for
free.
Should
we
worry
at
all
about
like
mixing
the
two
or
it's
completely
transparent,
or
it's
something
that
worried
a
user?
It's
something
that
we
should
take
in
care
and
a
UI,
for
example,
to
identify
what
is
chocolate
and
what
is
pure,
no
gate
and
so
on.
Good.
A
Question
yeah,
so
Nexus
doesn't
bother
distinguishing
lis
between
chocolaty
and
nougat
and
I.
Think
that
that's
a
reasonable
place
for
get
lab
to
be
Pro,
get,
does
distinguish
and
I
think
it's,
because
they
provide
a
GUI
and
that's
their
there.
That's
part
of
their
value.
So
if
you
call
something
a
chocolaty
feed,
they're
gonna
get
as
close
to
chocolaty
as
possible
and
now
nougat
and
chocolaty.
Don't
look
so
similar
anymore
on
their
UI,
so
that
allows
program
to
make
to
do
an
update
where
they
then
sync
to
the
current
chocolaty
GUI.
A
So
I
think
any
and
distinctions
are
only
if
you're
trying
to
present
a
GUI
for
the
feed
or
like
a
catalog,
and
if
you
want
it
to
look
like
the
target
feed
but
as
an
API
set
for
CI
CD,
yeah
I,
don't
every
most
mature
shop
should
understand.
There's
no
difference.
Basically,
if
I
want
to
do,
chocolaty
I
go
into
the
product
and
say
give
me
a
nougat
feed
and
then
I
pump
in
chocolaty
packages
and.
A
It
can't
be
done
well
so
with
nougat,
it
resolves
all
dependencies
and
whatever
sledded
list
of
sources
you
give
it
a
cross
source
Louis.
A
second
nougat,
regular
nougat
packages
may
not
cross
feeds,
I'm,
not
sure,
but
I
know
chocolate.
He
can
for
sure.
So
if
I
have
an
internal
package,
it
depends
on
packages
that
are
only
in
the
public
feed.
I
can
say:
chocolaty
install
my
cool
package
sources,
nougat
org
and
my
internal
feed,
and
it
will
resolve
dependencies
across
that
there
is.
A
There
is
no
very
low
chance
of
someone
mixing
putting
chocolaty
dependencies
in
a
nougat
package
or
nougat
dependencies
in
a
chocolate
package,
so
they
both
basically
resolve
I'm.
Not
sure,
though
you
could
test
it,
it
might
actually
work
to
put
nougat
I
package
IDs
in
a
chocolaty
package
and
make
sure
that
nougat
is
on
there.
But
I.
Don't
know
that
it's
gonna
position
them
like
the
nougat,
the
bear-
client.
Would
it
might
just
extract
it?
Go
there's
no
chocolaty
install
here.
So
we
have
would
be
hard.
A
A
A
So
if
you
I
try
to
be
aware
of
and
sense
where
the
windows
packaging
community
is
where
the
windows
devops
community
is
for
automation
and
CI,
CD
and
deployment
automation
and
then
I'm,
aware
of
most
of
parts
of
Linux
I'm
I'm
growing
in
my
dependency
manager
stuff,
so
like
maven
NPM,
these
aren't
things
I've
dived
into
I'm
I
do
apt-get.
I
do
yum,
so
I'm
still
growing
on
that
side.