►
From YouTube: Package Registry Naming Conventions
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
at
the
group
level
that
takes
a
step
in
word
where
you
provide
some
sort
of
identifiers
about
the
group,
and
this
is
kind
of
the
change
we
made
with
NPM.
We
moved
NPM
from
the
instance
level
to
the
group
level
in
order
to
handle
subgroups.
So
if
you
recall,
we
had
discussed
stew
options
with
NPM,
one
was
create
like
a
delimiter
separated
name
using
the
full
path
of
the
project
and
I
used
that
as
part
of
the
package
name.
A
So
you'd
have
like
a
really
long
package
name
and
that
spells
out
the
whole
path
and
that
was
kind
of
like
well.
It
doesn't
make
a
lot
of
sense,
because
it's
long
nobodies
can
ever
remember
those
sure
it
would
work
with
CI
and
automation
like
that.
But
in
terms
of
being
able
to
remember
and
look
things
up
quickly
and
jot
things
down,
it's
not
very
useful
and
also
with
NPM
there's.
A
A
problem
of
NPM
doesn't
allow
for
the
slashes
that
are
within
a
path,
and
certainly
a
full
path
of
a
project
might
have
many
many
slashes.
So
to
get
around
that,
we
just
said:
okay,
well
we're
just
gonna
enforce
the
top-level
group
name
or
namespace,
and
then
from
there
there
can't
be
any
duplicate
names
underneath
that
namespace
and
so
NPM
is
kind
of
working
at
the
group
level.
Right
now
to
an
extent
where,
as
may
have
been,
has
both.
A
B
A
A
The
Konan
is
the
same
way
you
can
slashes
are
important
in
the
naming
as
well.
However,
conan
also
III
in
in
working
through
Konya
I
discovered
that
we
can
is
a
plus
sign
as
a
delimiter
between
the
path
and
that
won't
create
any
issues,
because
pluses
are
not
allowed
in
project
names
on
gate,
lab,
I,
believe
I'm,
actually
I
should
double
check
that,
and
so
that's
the
instance
level
endpoints
for
Conan,
argue
or
instance,
level
package
names
for
Conan
is
going
to
include
the
plus
separated
path
of
a
project.
Okay,.
B
A
I
just
need
to
check
that
just
to
make
sure
it's
like
the
same
for
packages
and
groups
and
all
of
those
names
and
so
moving
forward
on
Conan.
The
next
step
would
be
adding
a
group
level,
and
that
would
be
similar
to
NPM,
where
the
the
piece
that
we're
using
right
now,
where
we
require
the
full
path,
I,
would
probably
set
it
to
just
require
that
top-level
group
name
and
then
from
there.
Everything
just
has
to
be
unique
within
that
group.
C
Can
I
can
I
make
like
a
very
dumb
question,
but
it's
like
is
Humber
in
my
head.
Why
do
we
need
all
these
like
why?
Why
can't
I,
just
host
like
I,
create
an
arbitrary
package
name,
even
if
it
really
exists,
let's
say
it's
a
popular
NPM
package
and
I'm
deciding
to
use
the
same
name,
maybe
I'm
patching
the
thing
myself
and
I
just
want
to
host
inside
my
I
account
like.
Why
can't
I?
Do
that?
Why?
Why
do
we
have
all
these
restrictions
and
rules
so.
A
The
sort
of
route
behind
that
it's
kind
of
similar
to
actually
the
same
problem
you
might
see
on
NPM,
but
we
can
kind
of
get
to
that.
So
the
the
route
behind
that
is
that
packages
are
identified
by
their
project,
so
they're
directly
related
to
the
project.
So,
if
you're
creating
a
package,
you
have
to
have
a
project
that
the
package
is
made
from.
A
So
in
order
to
identify
where
that
package
exists
in
gate
lab,
we
need
to
be
able
to
identify
the
project
and
decide
if
you
have
permissions
to
read
that
project,
because
we
allow
for
private
projects
and
that's
what
ties
in
whether
or
not
the
package
is
going
to
be
private
as
well.
So
what
happens
is
if
you
wanted
a
package
name
like
if
you
just
wanted
a
package,
let's
just
say,
like
you
know,
like
GG's
package
and
all.
A
You've
already
got
the
name
taken,
so
they
can't,
but
at
some
customers
they
might
very
specifically
need
that
because
it
already
exists
for
them
or
they
don't
care
about
the
external
packages
they
want,
and
they
want
to
be
able
to
me
in
the
packages
their
own
very
specific
names
within
their
company,
and
so
that
kind
of,
especially
on
gitlab
comm
ties
us
down
to.
We
have
to
have
some
way
to
make
these
unique.
C
A
C
A
Is
how
the
maven
that's
how
the
maven
package
manager
is
set
up,
so
you
can
use
your
source
URL
your
registry
URL,
and
you
can
set
it
you
can.
You
could
use
the
project
ID
and
that
will
you
know,
say:
hey
I'm
only
going
to
look
for
projects
or
for
packages
within
this
project
you
can
use
a
group
ID
and
then,
when
you
try
to
download
packages,
it
will
only
look
for
packages
within
that
group
or
you
can
use
the
generic
get
lab
URL.
A
That
has
no
identifying
characteristics
and
that
will
be
open
to
anything
you
have
access
to
on
get
lab,
so
that
is
sort
of
the
idea
of
how
we
should
set
these
up
is
that
there
should
be
a
different
like
endpoint
for
each
of
those.
The
trick
is-
and
we've
seen
this
with
some
of
the
customers
is
that
they
don't
want
to
configure
these
large
numbers
of
registry
endpoints.
They
want
to
just
be
able
to
use
one
for
their
entire
company
by
example.
A
Edge
cases
like
that
I
see
and
this
kind
of
comes
back
to
what
I
talked
with
Tim,
about
where
one
possibility
that
we
could
look
at
is
we
treat
self-managed
instances
separate
and
give
them
the
option
to
flip
a
switch
to
say
that
you
can
name
any
package
on
the
instance.
Anything
you
want
because
they're
the
only
ones
using
the
instance
they
know
who's
using
it.
They
know
what
their
packages
are,
so
they
should
be
able
to
use
very
distinct
package
names
and
not
have
to
tie
them
to
anything.
C
A
B
D
B
A
A
Project
and
your
package
is
public.
Anyone
would
be
able
to
find
it
and
use
it
if
they
want
to
that's
I
mean
it's
open
source,
pretty
much
yeah
I
think
that
would
be
a
very
cool
thing
to
do.
They
like
it
like
it's,
it's
it's
kind
of
like
I'm,
trying
to
think
of
like
how
that
would
work,
and
it's
it's
still
a
little
abstract
I
mean
I
feel
like
all
of
this
is
still
a
little
abstract,
like
even
talking
through
how
these
different
end
points
point
to
the
repository
I'm
like
wait.
B
B
It
allows
us
to
really
create
that
social
aspect
of
the
registry.
If
we're
able
to
do
that
at
least
on
the
instance
level,
which
I
know
it's
more,
what
Sid
I
just
talked
to
Nick
a
little
bit
about
this
and
Sid
mentioned
he's
not
really
interested
in
us
doing
that
as
much
the
open
source
like
kept,
making
sure
that
every
package
created
lives
on
get
lab,
but
we
do
want
to
do
inner
sourcing.
A
That
makes
sense
and
I
think
that
that
the
solution
that
is
find
a
way
to
provide
that
instant
level
access,
or
instance,
level
access
on
self-managed,
especially
and
then
I'm
Gil
I'm
calm,
just
make
sure
that
we
always
keep
in
mind
the
the
group
endpoints,
because
that's
as
high
level
as
you
can
get.
If
you
have
no
multiple
groups
on
Gilad,
calm.
B
Okay
and
so
to
summer,
maybe
to
summarize
any
we
could
still
change
our
mind,
but
it
sounds
like
what
we're
thinking
is
to
do.
Two
different
experts
are
two
different
experiences
for
babcom
users
and
self
manage
users
and
self
manage
with.
We
would
provide
more
flexible
naming
conventions
where
we
didn't
tie
them
to
use.
The
specific
group
instance
in
group
level,
identifiers,
Xin,
the
endpoint
yeah.
A
B
A
I
this
is
it's
difficult
to
think
about,
like
I'm,
like
trying
to
think
of
the
technical
aspect
of
what's
happening
there.
So
NPM
only
has
one
endpoint
right
now,
so
I
think
there's
a
couple
so
I
think
what
we
should
do
probably
is
go
through
and
add
the
secondary
endpoint
that
isn't
there
right
now,
which
well
I
mean
think
about
this,
because
because
the
endpoint
we
have
is
pretty
much
an
instance
level
endpoint.
So
all
we
really
need
to
do
is
there's
the
validation
set
up
on
the
naming.
D
B
A
All
right
so
actually
the
the
documentation
that
I
linked
to
there's
a
section
where
it
says
group
level
and
instance,
level.
Endpoints
are
good
to
have
but
optional
to
avoid
name,
conflicts
or
instance,
level
endpoints.
We
use
the
package
naming
convention
and
that
points
to
the
documentation
that
I
removed
the
instance
level
names
from
so
it's
kind
of
it's
a
there's,
a
little
there's
a
little
disconnect
in
there,
but.
B
A
C
B
B
Then
we'll
we,
we
still
are
gonna
have
this
case,
sometimes
where
we're
only
allowed
so
many
slashes
right,
like
with
Conan,
and
so
it
sounds
like
our
preference
is
we
have
two
things
and
for
get
lab
calm
and
for
self-managed,
and
then
we
have
for
integrations
that
allow
slashes
and
that
don't
allow
slashes,
and
then
we
have.
That's
really
is
yeah.
A
And
it'll
be
sort
of
any
special
character
about
the
package
manager
uses
in
a
special
way.
We
just
kind
of
have
to
be
on
the
lookout
for,
for
if
we
use
those
in
specific
ways
or
if
we
allow
them
in
our
project
names,
but
they
don't
allow
them
in
their
package
names
like
all
sorts
of
stuff
that
could
cause
confusion.
We
just
need
to
make
sure
that
we
understand
what
those
overlaps
are.
If.
A
D
B
A
A
I
think
that's
definitely
something
that
that
could
be
useful
and
I.
Think
that's
gonna,
like
I,
think
the
long
term
idea
of
package
discovery
I
think
in
one
of
the
epics
there's
something
about.
You
know
like
being
able
to
search
for
packages
and
and
such
better
and
faster
way
and
so
I
think
that's
going
to
kind
of
tie
a
little
bit.
Yeah.
B
I,
like
this
idea,
I
feel
like
I
feel
much
better
after
this
meeting,
because
I
really
like
when
we
were
talking
about
it.
I
was
talking
about
it
with
some
customers
and
then
some
other
people
were
asking
about
an
issue
and
I
was
like
my
head
just
started
spinning,
but
I
feel
like.
That
was
a
very
great
explanation.
Thank
you.
I.
A
A
B
A
B
But
we
know
that
we're
gonna
want
to
expand
it
to
group
levels.
So
I'm
I
want
to
make
sure
that
we're
helping
Otero
to--and
that
we're
also
like
have
a
standardized
way
for
how
we
approach
these
things
and
and
I
didn't
feel
like
I
was
leading
us
in
that
direction.
I
didn't
feel
like
oh
we're
following
the
same
NPM,
it's
different,
mavens,
different,
Conan's,
different
and
so
I
just
want
to
like
level
set
across
all
of
them.