openwrap/openwrap

The OpenWrap repository

OpenWrap

OpenwWrap is a pacakge manager for .net.

To get started, read the QuickStart or go to the Homepage.

openwrap's Issues

Support edge versions of packages

Packages are all included in repositories. Some packages must be marked as "edge" packages, and only usable when such a tag is applied to the dependency import.

It would be nice to have this as a generalized mechanism along the lines of the namespace support in C#.

For example:
nhibernate-3.0.0.1.wrap
namespace: edge

and in your consumer:
depends: edge/nhibernate

and the command-line
add-wrap nhibernate -namespace edge

This would also allow complete distributed categorization of content, letting you only import pacakges you're happy to search for.

wrap remove: Remove wrap from system repository

remove-wrap does not remove packages from the system repository. Need to have a -system.

removes all versions of a package present in the system repo:
remove-wrap package -system

removes a specific version of a pacakge in the system repo:
remove-wrap package -system -version

wrapdesc should have a reader / parser component to load / save it

wrap update: -system errors when update for a package isnt found

NamespaceNotFound doesn't display friendly error message

Support authentication when publishing to remote repositories

VS caches msbuild tasks

VS caches msbuild tasks, which in turns caches the version of an assembly at the moment a project was loaded. Need to force a refresh of dependencies when a rebuild occurs.

Installer for o.exe

Need to build an msi installer and an rpm package for openwrap

Failing dependency resolution error message doesn't specify which dependency couldnt be found

add-wrap adds dependencies even when they already exist

Resharper integration should trigger a project ref import on first load

Right now, the resharper integration doesn't add the project references until the first build. Need to automatically run a parse and integrate references on the first load.

Web repositories use a local cache for index download

Currently, remote repositories are contacted on each request, retrieving the whole list. Need to persist the index in the OpenWrap system folder, together with LastModifiedDate for the file.

The web repositories should then be updated to use the cache version, and in parallel issue a conditional get to update it. If an update is available, a message should be issued to the user to let him know that re-issuing the command may have updated packages. Alternatively, issue the http request with a low timeout and ocnditional get per-request, and simply fall-back on cache when connection fails, or use network location-like systems to "know" if openwrap is live or not.

Package signing using self-generated or code-signing keys

Refactor commands to IPackageManager

Either IPackageManager needs to get a more general API, and logic in wrap commands be moved, or that logic needs to be extracted to a different abstraction. The existing code has too many moving parts.

Repository types to be extensibles as part of packages

Dependency overriding

allow aliasing of dependencies to custom builds, like:

override nhibernate2.1 nhibernate2.1-custom

Warn when dependencies conflict with the GAC

If an assembly is in a package one takes a dependency on, and that assembly is in the GAC, there should be a big warning, maybe with an offer to remove the assembly from the GAC (MVC anyone?)

Support for NuPack repository and package format

Support NuPack atom feed format as a read-only package source, and a package format converter to convert a NuPack package to OpenWrap on the fly.

This could be also implemented as a convert-legacypackage blah.nupack blah.wrap command

Unix file system doesn't support temp directory

o.exe.link not containing the correct path on mono *nix

customizing of remote repositories list

Remote repositories currently only point to an arbitrary location. Need to make the list extensible, which requires:

• o wrap server -add
• o wrap server -remove
• o wrap server -list (default)
• A way to store personal settings in the existing OpenWrap system repositories. In this case, a simple list of URIs following the text/uri-list media type should be enough, stored in a .servers file.

help get: Provide a list of commands and per-command input descriptions

The help command is pretty much useless at this stage. It needs to be expanded with, for each command, a name, a description, and automatically try and locate resource-based "documentation" based on command name / parameter, falling back on the attribute value when it's missing (so localization is doable easily later on).

deleting a folder that needs to be a junction fails on first run

XP seems to happily take a lock on a junction while running msbuild, preventing openwrap from deleting the folder and restoring the junction.

Support array of values in commands

Commands must be able to receive lists of values using
-input value1, value2, value3

Command parser doesn't process CamelCase and shortened properties

Currently, command parameters are only read in full.

The command-line parsing should support shortening both on CamelCase and on shortened parameter names.

given command parameter HasCommand
when parsing the parameter with examples (-HasCommand, -hc, -hasc)
then command parameter is assigned

wrap add / update: -force to overwrite packages

Adding a dependency that already exists still adds an entry to the descriptor

The following:
add-wrap openwrap -content
add-wrap openwrap

Will result in the following file:
depends: openwrap
depends: openwrap content

If an entry is already present, it should be updated, and the descriptor should read
depends: openwrap

Update configuration language

Update configuration language to be of the form
Key: Value

At the moment, it's Key=Value instead.

alternative command name syntax

Current commands are called by using name verb, should also support the verb-name notation.

e.g.
o wrap install
and
o install-wrap

Automate building a wrap from source control (Git)

Consider implementing an auto-build from source control followed by a publish

Perhaps in the form:

build-wrap git://; test-wrap; publish-wrap git://

adding package from another path adds the path component as the wrap name

Platform compatibility tables are extensible in configuration

Platform compatibility (aka which platform can consume which assemblies and in which order in the /bin exports) is currently fixed. It would be immensely useful to refactor that code to make it changeable in one place in the codebase, so silverlight / mono / cf profiles could be added easily.

Support a publish mechanism that expects a HREF

It would be ideal if we could publish a wrap and rather than expecting an upload it expected a href.
This would provided simpler support for distributed package storage with an eye on using the GitHub "Releases" mechanism for storing wraps along side source code.

wrap set: Update a wrap dependency in the project repository

When a wrap is already part of a descriptor, set-wrap lets the descriptor be updated:

set-wrap package -content [true|false]
sets or unsets the content flag

set-wrap package -anchored [true|false]
sets or unsets the anchored flag

set-wrap package [-minimumVersion x.x.x] [-maximumVersion x.x.x] [-version x.x.x] [-anyVersion]
min and max can be used together, version sets the exact version, anyVersion removes need to specify version
For new contributors, versions are added by adding VersionVertex classes.

Order remote wrap repositories

The list of remotes is not relevant right now.

The remotes need to be prioritized so one can choose which repository is probed first.

The list-remote should present the current 1-based index when rendering. Changing the order should be done by a new command:
set-remote remotename -position 1

IndexedFolderRepository exposes the package folder path

wrap add: use -minversion -maxversion -version -anyversion

add-wrap uses -version at the moment to specify a version string (< 2.1 and >= 2.0). Command-line tools don't support those characters easily.

Replace by -version (for exact version), -minversion, -maxversion (can be used together), -anyversion.

When package already part of the dependency, update the dependency rather than error out.

Pre-openwrap dependencies loaded carelessly

OpenWrap doesn't currently respect dependnecy management on entrypoints (ConsoleRunner / Initalize build task, etc). Need to refactor the assembly loading code to support using a "driver" for finding files, and pre-load openwrap dependencies before anything else runs.

Replace the Version class use by a custom PackageVersion type

The Version class does not support wildcard, which we use. Other package formats (such as semantic package versioning) support tagged versions (1.0.0beta) which is something we may consider in the future.

Replacing the code with a custom VersionDeclaration type with proper ToString, operator overloading and equality would make the code much better and provide for future extensibility more easily.

Every package with Anchored: true is being anchored

The UncompressedFolder should not try and anchor a folder if its not the latest version in a folder.

openwrap .wrap package not uncompressed when found on initial o.exe invocation

o.exe looks for openwrap in _cache and fails if not found, even if the .wrap file is in the /wraps folder. o.exe should attempt uncompressing to a folder when the .wrap file is found.

Implement file / folder monitoring on IFileSystem

Provide installation / update / removal hooks for both system and project repositories for packages

Automatically remove old versions of a package in project repository upon successful add

Rollback installation of package list when one package fails

Anchoring support for dependencies

By default, dependencies live in /wraps/cache/packagename-1.0.0/. The problem is that, while cache should never be checked-in, some packages have content that are needed, in a version-independent way, for a fresh pull to function.

The main example is openwrap itself, where all references end up probing the cache folder.

The design for anchoring provides for an extension to the dependency language
depends nhibernate = 2.0 anchored

When such dependency is defined, a few things happen:

• A symlink is created between /wraps/cache/nhibernate-2.0 and /wraps/anchored/nhibernate. This will ensure that the folder is checked-in as files.
• When a package is opened, a check is made to ensure that the folder /wraps/anchored/nhibernate is indeed a symlink and not files. If it is files (aka a fresh copy was just pulled from source control), the folder is deleted and the symlink is re-established

Implementing this requires using junctions on ntfs drives, and some way of doing this on mono, with a fallback for FS that don't support them. To achieve that, a junction-like API should be created, with a default implementation that keeps files in sync with the master. Then implementations can be swapped-in based on platforms.

Upload pacakges to remote repository

Resharper 5 integration

The resharper integration module (that lets resharper be notified of pending assembly updates) is built for resharper 4.5.

A version for 5.0 needs to be compiled against the 5.0 assemblies. Ideally, the code would detect which version to use based on the state of the vs process upon load.

wrap update: Update packages by name

o bombs out if the wraps folder includes more than one version of a package