FubuMvcArchive / bottles

OBSOLETE - Modular runtime packaging for .Net applications
http://fubuworld.com/bottles
Other
26 stars 16 forks source link

Are dotfiles appropriate for Bottle configuration? #72

Open KevM opened 10 years ago

KevM commented 10 years ago

I ran into an issue packaging a release where we include the source code and the bottles config files .link and .package-manifest didn't make it because there are considered hidden and not copied by unixy (rake in this case) file operations. There is a workaround :

Dir.glob('source/**/*', File::FNM_DOTMATCH)

The problem is you have to be careful then to not include other dotfiles you don't really want in the release. Like the .git folder.

This seems like a smell to me. The idea behind dotfiles is that they are normally hidden. Bottle's usage of them is to connote a configuration file.

I don't feel too strongly about this just wanted to share my pain and see if it resonates with anyone.

jeremydmiller commented 10 years ago

Kevin,

Are you still using Zip bottles? While you could use .links for real production deployment that's meant for development time linking and I usually recommend those even get ignored by Git. The .package-manifest isn't necessary unless you're using a zip bottle or are doing something outside the defaults for an assembly bottle like dependencies.

Are you still hitting the issues where you have to pre-explode the bottles because of file permissions on the real server?

On Oct 2, 2013, at 9:01 AM, Kevin Miller notifications@github.com wrote:

I ran into an issue packaging a release where we include the source code and the bottles config files .link and .package-manifest didn't make it because there are considered hidden and not copied by unixy (rake in this case) file operations. There is a workaround :

Dir.glob('source/*/', File::FNM_DOTMATCH)

The problem is you have to be careful then to not include other dotfiles you don't really want in the release. Like the .git folder.

This seems like a smell to me. The idea behind dotfiles is that they are normally hidden. Bottle's usage of them is to connote a configuration file.

I don't feel too strongly about this just wanted to share my pain and see if it resonates with anyone.

— Reply to this email directly or view it on GitHub.

KevM commented 10 years ago

Guessing we are zip as we use bottle runner to create pak-*.zip files as part of our build process. We like the fact that the content directory gets packaged with the bottle and doesn't need to be in the .csproj.

<package xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Role>module</Role>
  <Name>Agent.Console</Name>
  <assembly>Agent.Console</assembly>
  <ContentFileSet Include="*.spark;content/*.*">
    <DeepSearch>true</DeepSearch>
  </ContentFileSet>
</package>

Can we do that with Assembly Bottles? We have not run into permissions issues yet.

jeremydmiller commented 10 years ago

Kevin,

When you create your bottles, are you using the "create-pak" command (zip bottle), or "assembly-pak"? Do you deploy an assembly w/ the pak*.zip files as embedded resources, or a zip file that contains the content and the assembly?

KevM commented 10 years ago

Assembly bottle build using fuburake.

We have a lovely bit or rake build automation goo to copy the resulting bottles into the web application bin directory to avoid having references I guess.

  #desc "Copy all bottles (and dependencies) assemblies linked to the Web project into the output bin directory"
  task :copy_linked_bottles do
    targetDir = 'results/release/app/bin'
    FileUtils.mkdir_p(targetDir)
    doc = ::REXML::Document.new File.new('source/Web/.links')
    assemblyPaths = doc.elements.to_a('//include').map { |e|
      bottleName = e.text.gsub("..\\", "")
      "source/#{bottleName}/bin/#{@solution.compilemode}/*.{dll,pdb}"
    }

    assemblyPaths.each do |link|
      puts "Assemblies in path: #{Dir.glob(link)}"
      Dir.glob(link) do |file|
        FileUtils.cp file, targetDir, :verbose => true
      end
    end
  end
jeremydmiller commented 10 years ago

So do you pre-explode the bottles and copy the app w/ the fubu-content folder, or just copy all the assemblies and let it explode on the server? I'm asking because I swear you brought that up on the list with a production server that didn't have write access.

Maybe you'll make me a liar, but I'm claiming that the .package-manifest is completely unnecessary except at bottling time for an assembly bottle, and it infers a default manifest for you if it doesn't exist anyway.

The .links file probably shouldn't be deployed anyway.

On Oct 2, 2013, at 2:46 PM, Kevin Miller notifications@github.com wrote:

Assembly bottle build using fuburake.

We have a lovely bit or rake build automation goo to copy the resulting bottles into the web application bin directory to avoid having references I guess.

desc "Copy all bottles (and dependencies) assemblies linked to the Web project into the output bin directory"

task :copy_linked_bottles do targetDir = 'results/release/app/bin' FileUtils.mkdir_p(targetDir) doc = ::REXML::Document.new File.new('source/Web/.links') assemblyPaths = doc.elements.to_a('//include').map { |e| bottleName = e.text.gsub("..\", "") "source/#{bottleName}/bin/#{@solution.compilemode}/*.{dll,pdb}" }

assemblyPaths.each do |link|
  puts "Assemblies in path: #{Dir.glob(link)}"
  Dir.glob(link) do |file|
    FileUtils.cp file, targetDir, :verbose => true
  end
end

end — Reply to this email directly or view it on GitHub.

KevM commented 10 years ago

This is not about deployment of the web app it is about packaging up the source for deployment as part of an on premise solution that other devs may hack on. I am observing that is a PITA to have dotfiles laying around as they typically don't get copied in normal situations.

I need the entire build chain to work so I need the .link and .package-manifest files. Sorry if I did not make that clear.

No pre-exploded bottles. As I mentioned we put the bottle assemblies into the web app bin directory.

I had a write access issue with FubuLocalization's default policy to write to missing.locale.config. Funny, I did not have that problem recently with a deployment I did but that is totally off topic.