Skip to content

Paket init overwrites "full" paket.exe with bootstrapper #2620

Open
@rmunn

Description

@rmunn

Description

The paket init documentation says that it "create[s] an empty paket.dependencies file in the current working directory." It says nothing about messing with the .paket folder, but running paket init will actually replace a "full" paket.exe file with a bootstrapper (named paket.exe so it will run in "magic" mode).

Repro steps

  1. Create an empty folder for a new project.
  2. Create .paket in the root of the new project's folder.
  3. Download paket.bootstrapper.exe and put it in the .paket folder.
  4. Run mono .paket/paket.bootstrapper.exe to download full-fledged paket.exe.
  5. Run mono .paket/paket.exe init.

Expected behavior

The paket.dependencies file is created as documented, but the existing paket.exe file is left alone since it's already the latest version of Paket.

Actual behavior

The 8M file .paket/paket.exe is replaced by a 50k .paket/paket.exe file, which is actually the bootstrapper.

Also, the Paket output prints the following:

Downloading file from https://github.com/fsprojects/Paket/releases/download/5.85.3/paket.bootstrapper.exe to /home/rmunn/code/fsharp/bugrepro/.paket/paket.bootstrapper.exe`

But this output is lying, because instead of creating paket.bootstrapper.exe, it overwrites the existing paket.exe file. After seeing that output, I expect the .paket/paket.bootstrapper.exe to exist, but it's not there. A newbie would be rather confused by this sequence of events.

Known workarounds

I can rename paket.exe to paket.bootstrapper.exe and re-run it to download the "full" paket.exe, but I'd rather see paket init behave properly: if the .paket/paket.exe file already exists and matches the checksum of the most recent Paket release, it should not be overwritten.

Proposed solution

  1. Rewrite the paket init documentation to mention that it does more than just create a paket.dependencies file.
  2. The logic for creating paket.exe should, IMHO, be as follows:
    1. If paket.exe already exists and its checksum matches the latest release of Paket, it should be left alone.
    2. If paket.exe exists and its checksum matches an older version of Paket, leave it alone but print a message to stdout, "Paket version 5.85.1 found, latest version is 5.85.3. Run (command) if you want to update to the latest version of Paket."
    3. If paket.exe exists and its checksum does not match any versions of Paket, it's probably corrupted. In that case, deleting it and replacing with the bootstrapper in "magic" mode does make sense.
    4. If paket.exe does not exist but paket.bootstrapper.exe does exist, then the user has probably set up this project to have paket.bootstrapper.exe checked into Git, and a build script that runs the bootstrapper before running paket.exe. (And they're also clearly running paket init from a copy of Paket located elsewhere on the disk). In which case the reasonable thing for paket init to do is to download the full paket.exe file, not the bootstrapper, as paket.exe for this project. A message to stdout explaining what is happening would also be a good idea.
    5. If neither paket.exe nor paket.bootstrapper.exe exist, then the current behavior (download the bootstrapper and rename it to paket.exe) is probably reasonable.
  3. For bonus points, it might be good to check for a .gitignore file in the current working directory (and possibly a .bzrignore or .hgignore file as well), and apply the following logic:
    1. If paket.exe (or .paket/paket.exe or .paket\paket.exe) is listed in the DVCS ignore file, but paket.bootstrapper.exe is not ignored, then do NOT rename the bootstrapper to paket.exe as that will cause problems for the user later on. Instead, leave it named paket.bootstrapper.exe: the presence of that line in their .gitignore file means that they probably have their build scripts set up to expect paket.bootstrapper.exe.
    2. If paket.exe is not listed in the DVCS ignore file, and the paket.exe is the full 8M Paket file, then do not touch it since it's probably already checked in and we don't want to make unnecessary diffs. (Unless the paket.exe is a corrupted download, in which case it should be replaced as mentioned above). But do print something to stdout to suggest "magic" mode, as the user may be unaware of that feature.
    3. If both paket.exe and paket.bootstrapper.exe are listed in the DVCS ignore file, print a warning to stdout, saying something like "You'll want to check the bootstrapper into version control, so that others can just clone your repo and build. We suggest removing paket.bootstrapper.exe from your .gitignore file." (Or "your .hgignore file" or "your .bzrignore file").

Related bugs

This may be related to #2451 and/or its resolution.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions