Way to "really clean" a project
Tony Sloane
The sbt "clean" command goes part of the way but only removes files from the target directory. It also leaves the target directory in place. Also, there are generated files in project/target, perhaps in project/project/target and so on, which are not removed by "clean".
Of course I can write my own script to do it, but making the script general enough to cope with all possible project structures is non-trivial. E.g., projects that are only configured using a top-level build.sbt won't even have a project directory to start with, so I want to remove it. However, I don't want to remove it if there is some config in their (e.g. plugins.sbt).
I tried things like running "sbt clean" in the project directory, which does remove project/target files, but also leaves new files behind.
I'd like a safe way at the top-level of a project to remove just those things that have been generated, without having to write a custom script. I don't see a way to do this with a standard sbt command? Have I missed something?
thanks,
Tony
Paul Phillips
> I'd like a safe way at the top-level of a project to remove just those things that have been generated, without having to write a custom script. I don't see a way to do this with a standard sbt command? Have I missed something?
The best way to do this is git clean -fxd . (but don't run that
without knowing what it does -- add --dry-run too.)
Tony Sloane
Ah, yes, good idea, thanks. I have to confess I'm not usually a git user, but my preferred VCS Mercurial seems to have an equivalent:
http://mercurial.selenic.com/wiki/PurgeExtension
I still believe that there should an sbt-way to do this. Not all projects are under version control.
Tony
Tony Sloane
And, of course, there may be new files in the project that are not yet under version control. In the end, sbt should know exactly what *it* has generated and should be able to remove just those files.
Tony
Paul Phillips
> I still believe that there should an sbt-way to do this. Not all projects are under version control.
That's their bug. I don't think one should go one millimeter out of
one's way to help people not use version control. It is programmer
negligence of the highest order. And there's no argument against it;
it doesn't matter if it's someone else's project, you just superimpose
your own version control.
Here's a handy alias for anyone thinking it's too much trouble:
alias gitify='git init && git add -f . && git commit -m "Initial commit"'
I know one can dream up scenarios where there is some kind of obstacle
to version control; the vast majority of the time you either have a
VCS or can impose a VCS.
Tony Sloane
Of course, VCS is important and extremely useful. But that doesn't change the fact that if sbt is capable of generating lots of temporary stuff, it should also be able to delete that stuff easily. Using a VCS provides a reasonable workaround for many projects, but it doesn't address the real problem here.
Tony
Paul Phillips
> And, of course, there may be new files in the project that are not yet under version control.
If files you haven't added to version control may be removed, it is a
valuable feature which imposes important discipline.
If someone was unhappy to have lost work that way...
Little Bill Daggett: You just shot an unarmed man!
Will Munny: Well, he should have armed himself if he's going to
decorate his saloon with my friend.
-- "Unforgiven", 1992
Eugene Vigdorchik
> On Thu, Apr 19, 2012 at 10:40 AM, Tony Sloane <inky...@gmail.com> wrote:
>> And, of course, there may be new files in the project that are not yet under version control.
>
> If files you haven't added to version control may be removed, it is a
> valuable feature which imposes important discipline.
You are missing files ignored in git, I think.
In general I think sbt should clean after itself, not touching the files unkown.
Eugene.
>
> If someone was unhappy to have lost work that way...
>
> Little Bill Daggett: You just shot an unarmed man!
> Will Munny: Well, he should have armed himself if he's going to
> decorate his saloon with my friend.
>
> -- "Unforgiven", 1992
>
> --
> You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
> To post to this group, send email to simple-b...@googlegroups.com.
> To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
>
Paul Phillips
> Using a VCS provides a reasonable workaround for many projects, but it doesn't address the real problem here.
I'm saying, explicitly, that using VCS is exactly the right way to do
this - if sbt attempted it, it would be redundant and I wouldn't use
it because there would be no reason to use something slower and less
accurate than the tool I already have - or at best it can aspire to
the same level of accuracy. The job at hand, "delete everything not
in VCS" (and that's exactly what "extreme clean" should be) is a job I
already know can be done exactly right every time, as rapidly as the
disk can respond to the delete requests, with a command to the VCS.
Tony Sloane
I guess we have to agree to disagree. Using a VCS to remove temp files created by sbt is both dangerous (despite one's good intentions about discipline) and tries to move the responsibility away from where it really should lie.
Tony
Paul Phillips
<eugene.v...@gmail.com> wrote:
> You are missing files ignored in git, I think.
You aren't with the command I gave. man git-clean.
Tony Sloane
But, "delete everything not in VCS" is *not* what I wanted to do. I wanted to "delete everything that sbt created as part of a build". These are clearly different things.
Tony
Paul Phillips
> But, "delete everything not in VCS" is *not* what I wanted to do. I wanted to "delete everything that sbt created as part of a build". These are clearly different things.
They aren't different in any way not covered by the options to git
clean. Or if they are, then there's your problem.
Tony Sloane
But again, you are pushing the burden onto git (a tool which many of us don't use) instead of placing it where it belongs (sbt, which generates the files in question).
Tony
Paul Phillips
> But again, you are pushing the burden onto git (a tool which many of us don't use) instead of placing it where it belongs (sbt, which generates the files in question).
"Where it belongs" is your opinion. I'd rather mark spent his very
limited time on something other than inferior clones of freely
available tools.
Eugene Vigdorchik
I sometimes have ignored files that I want to _keep_ rather than
delete. The reason I have those is that it's comfortable to have them
in the root of the project to be picked by sbt plugin. The reason I
want to ignore the file is that it contains private info that I don't
want to share. Is it my problem? I rather doubt.
Eugene.
Tony Sloane
Perhaps it is more effective for the community if sbt is enhanced by one person rather than requiring all of us to switch to git whether we want to or not...
Tony
Eugene Vigdorchik
Eugene.
>
> Tony
Bart Schuller
On Apr 19, 2012, at 1:45 PM, Eugene Vigdorchik wrote:
> On Thu, Apr 19, 2012 at 4:37 PM, Paul Phillips <pa...@improving.org> wrote:
>> On Thu, Apr 19, 2012 at 1:33 PM, Tony Sloane <inky...@gmail.com> wrote:
>>> But, "delete everything not in VCS" is *not* what I wanted to do. I wanted to "delete everything that sbt created as part of a build". These are clearly different things.
>>
>> They aren't different in any way not covered by the options to git
>> clean. Or if they are, then there's your problem.
>
> I sometimes have ignored files that I want to _keep_ rather than
> delete. The reason I have those is that it's comfortable to have them
> in the root of the project to be picked by sbt plugin. The reason I
> want to ignore the file is that it contains private info that I don't
> want to share. Is it my problem? I rather doubt.
That's a very valid use case, and it's what .gitignore files are for. The interaction between git-clean and ignored files is to leave them by default, but with an extra option they can be cleaned as well.
I would also like to explain why I too think using a VCS is the right answer to this question and why you won't see a built-in command
soon.
1) sbt needs a number of files itself in order to run. It would have to remove class files and jar files that it's currently running when doing a realclean. I'm not sure whether that's a problem on any OS, but I'm thinking it could be.
2) sbt doesn't actually know which files "it" generated. Ultimately what gets run when you issue an sbt command is determined by the base functionality of sbt, global build files, global plugins, project build files, project plugins, and all of their dependencies recursively. Every single piece of code could decide to create a file anywhere it wants, at any time, without telling anyone.
The only reliable way to battle 2 would be for sbt to implement its own VCS, which can't be the right answer :-)
Regards,
Bart.
Tony Sloane
>
> On Apr 19, 2012, at 1:45 PM, Eugene Vigdorchik wrote:
>
>> On Thu, Apr 19, 2012 at 4:37 PM, Paul Phillips <pa...@improving.org> wrote:
>>> On Thu, Apr 19, 2012 at 1:33 PM, Tony Sloane <inky...@gmail.com> wrote:
>>>> But, "delete everything not in VCS" is *not* what I wanted to do. I wanted to "delete everything that sbt created as part of a build". These are clearly different things.
>>>
>>> They aren't different in any way not covered by the options to git
>>> clean. Or if they are, then there's your problem.
>>
>> I sometimes have ignored files that I want to _keep_ rather than
>> delete. The reason I have those is that it's comfortable to have them
>> in the root of the project to be picked by sbt plugin. The reason I
>> want to ignore the file is that it contains private info that I don't
>> want to share. Is it my problem? I rather doubt.
>
> That's a very valid use case, and it's what .gitignore files are for. The interaction between git-clean and ignored files is to leave them by default, but with an extra option they can be cleaned as well.
I imagine that the problem would be to make sure that only the right ignored files get deleted, since many generated files would be ignored normally. Of course this behaviour can be customised, but that's not a long way away from making each user write their own cleanup script, which I was trying to avoid.
> I would also like to explain why I too think using a VCS is the right answer to this question and why you won't see a built-in command soon.
>
> 1) sbt needs a number of files itself in order to run. It would have to remove class files and jar files that it's currently running when doing a realclean. I'm not sure whether that's a problem on any OS, but I'm thinking it could be.
Yes, you may be right. But it's not necessarily the case that a "really clean" command would have to support sbt continuing to run. My use case is to reset the project to a state where it would need to be reinitialised as if it was the first time you ran sbt in there. My most common reason is that I'm trying out plugins, something doesn't work and I want to make sure that a new config works from a clean state.
> 2) sbt doesn't actually know which files "it" generated. Ultimately what gets run when you issue an sbt command is determined by the base functionality of sbt, global build files, global plugins, project build files, project plugins, and all of their dependencies recursively. Every single piece of code could decide to create a file anywhere it wants, at any time, without telling anyone.
Perhaps it is not possible to do it in general, but I think it's unfortunate that a tool like sbt that is providing so much "black box" assistance is unable to help more in this case. There are many parts of an sbt project that are clearly generated and could be deleted on request. Ideally an sbt user should not have to worry about managing dirs like project/target and project/project/target etc. Requiring the user to go off and work out their own solution seems like a cop out to me since it breaks some of the abstraction that sbt provides.
> The only reliable way to battle 2 would be for sbt to implement its own VCS, which can't be the right answer :-)
Agreed!
cheers,
Tony
Josh Suereth
Not sure that will ever happen. The clean task relies on the configuration in project/target et. Al. You can't clean the thing running the clean.