repository hint in wrap descriptor
Ruben Vandeginste
Suppose you are working on a project that includes both public and
private packages.
Public packages are deployed on a public repository with world-wide
anonymous read access.
Private packages are deployed on a private repository with read-write
access for your team members.
It seems likely that at some point in time, someone accidentally
deploys a private package to the public repository. To prevent this, I
think it might be a good idea to provide a repository "hint" in the
package descriptor. On publishing a wrap, it would by default be
deployed to the repository from the package descriptor. Then there's
still a choice if one should include a "real" repository in the
package descriptor, or a "name" that corresponds to one of the
"registered" repositories.
Good idea or bad idea?
cheers,
Ruben
Sebastien Lambla
A lot of people have suggested that some repositories ought to be available / deployed on a per-project basis (so you could autoconf your remotes per project). I think that's a valuable idea, and implementation would be rather easy.
What you are proposing would be a default remote per project, which begs the question, should we implement the default repository as something that is available for your per-user remotes? And should we then have shared repository settings and user settings?
Last question, should we make a difference between shared repository settings and private ones (think default repository as shared, but user-name not shared)?
This is all rather easy to implement from the existing code-base.
Seb
Ruben Vandeginste
I was basically proposing a default publish remote for a package.
I do not completely understand what you mean with repositories that
ought to be available/deployed on a per-project basis. Do you mean
that each package contains a list of all remotes that it needs for its
dependencies?
So, for example, you have a package A with dependencies AA, AB and AC,
which in turn have dependencies ABA, ABB and ABC. In that case, we
just need to add the remote that contains A to the user remotes.
Package A contains a list of remotes to fetch its immediate
dependencies AA, AB, AC. And those packages in turn contain again a
list of remote to fetch their immediate dependencies. Do you mean
something like this?
What that comes down to, is that packages will be much more self-... I
can't find the word right now, but what I mean, is that you can check
out a package from source control, and you don't need to worry about
the dependencies: they will automatically be pulled in from the right
repositories.
What I'm suggesting, is to add to that the remote where the package
itself lives, and thus the remote where a new version of the package
should be published. This would then be project/package specific I
think, and should not be available as a per-user remote.
Of course, one should always have the choice to publish to a
user-remote. In my use-case we will definitely be using project (in
the sense of project consisting of several solutions and packages)
specific repositories, and at first I just thought about doing things
manually, which is a bit dangerous for making mistakes.
The problem with usernames/passwords when one adds remotes in the wrap
descriptors... would it be possible to have something like a
xxx.wrapdesc.local next to the existing xxx.wrapdesc? This could be
used to override a default remote, but also to list a
username/password, and for providing "overrides" for for example
debugging purposes.
Ruben
Sebastien Lambla
What is currently in the code (but not enabled yet) persists the location from which any package has been added, and all those remotes will get added automatically when doing dependency resolution. It doesn't quite let a package tell you where the packge it depends from is though, as the dependent package is not there yet (so you can't read its descriptor).
So let me try and split between the various "features" i think we're talking about.
1. persist where a package came from when it was aded
This is already in the latest code, I've not enabled the funcitonality yet. The idea is that when you add a package from any repository, we now persist where it came from and what current version is in use.
This means that provided you check-in the /wraps/packages file, anyone pulling your project will automatically get that repository configured for them, so an update-wrap will magically find the repository this stuff came from.
2. persisting source of dependent packages in descriptor
I think what you're asking is if we do
o add-wrap package -from http://myserver/
We already persist the location of the package in your current project, but we don't add that information in the descriptor itself, so the package you produce doesn't have that information.
We could add it as some info in the descriptor, something like:
depends: package;source=http://myserver
But from an implementation perspective it may be a bit complicated, as we'd have to dynamically find the repository, and rerun the resolver, until we don't have missing packages anymore. An interesting idea however.
3. Configure repositories per project
The problem with (1) is that if you remove a package from a solution that came from that repository, it's not there anymore.
As you know, user repositories are added to user-level configuration. I was suggesting that we *could* provide a way to automatically make avaialble certain repositories by adding a project-level configuration that you can commit and share with colleagues. This could change any setting that's defined in config on a per-user and override it.
Hypothetically, you would have:
o add-remote nuget (-global) <-- avaialble for the user
o add-remote nuget -shared <-- configured in a project and available to be checked-in (say /wraps/config/remotes)
o add-remote nuget -user <- configured in a project but only avaialble to the current user (say /wraps/config/remotes.user)
You woudl then be able to check-in the file and that config will be available for all users. You can then override whatever you want in your local user file.
That said, it's not possible to share remotes with authetnication with colleagues, because te password gets encrypted per-user. Sharing passwords would then just break.
I think if we have those settings, then you'd always get userRepos.Concat(projectRepos).Concat(globalRepos). As repositories are already prioritized, we can then simply make the publish command without a remote go to the first configured writeable repository, and we could add another config setting that override this:
o set-config default-repository myRemote
I think that covers what you were asking for, what do you think?
Seb
________________________________________
From: openwra...@googlegroups.com [openwra...@googlegroups.com] on behalf of Ruben Vandeginste [ruben.va...@gmail.com]
Sent: 27 October 2011 08:04
To: openwra...@googlegroups.com
Subject: Re: [openwrap-devl] repository hint in wrap descriptor
Ruben Vandeginste
About (1), the packages file is automatically managed by update-wrap?
I think that is a good solution. I think (1) is actually better and
more simple than (2). I suppose that the packages file can also be
managed manually? I list the dependencies manually in the descriptor,
and I list the required repositories in the packages file.
About (2), I understand that it gets more complicated with the
resolving. Every package that is pulled in, can contain new references
to new repositories, which can possibly contain newer versions of
packages that have already been pulled in, etc. This is probably not
the way to go.
I like (3). With (3) it would be possible to add a public read-only
repository, and let the user add a publish repository that needs a
username password. And one can always add a README to tell the user to
add a required repository with his own username and password. I really
like (3) and it does indeed cover the things I asked. :)
Ruben
Sebastien Lambla
________________________________________
From: openwra...@googlegroups.com [openwra...@googlegroups.com] on behalf of Ruben Vandeginste [ruben.va...@gmail.com]