foobara 0.0.1 → 0.0.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 60f90ff595c7b792b48db28577cd347d04b3419f1e8d26a58ee4f3e7b5210b69
-  data.tar.gz: 55a434b5f26b54d7366a985d9a693ce6bb651702db35a16730fb555e60ec8b4e
+  metadata.gz: 782f9f751e5ade5abc8f593f9f3fb6afe456df2d2a5636554652432ff44722e5
+  data.tar.gz: ce77c639a1a7e5f9c79833610655e65ee6ed5e8051ce77c19ca43bbb58c748eb
 SHA512:
-  metadata.gz: 5968d4a44041c738a939e26a515659291685eb4329b93d88dadcaf75c39c8a467aaf2e83e3752f0e6b75e47b0c8fbbf865ed3366bf8894b1758eb63b2aec9d3e
-  data.tar.gz: bbb716a12e804ed7243d874c9fb8d216976f8be51a0e6b46fc66031e81cd8901e5aa9ac08baf7ca355c6ddce0088e75e1bbde28b3fca2afb507dbb8635a066ed
+  metadata.gz: dfce0e9aec6e7b6212ee1bc236e8bca42fba3a380ddce7a2fe75db012f738c3ad13d41a9f8d98438d18252ba92f3a87b90cdb5087d5cfc19006672d6d519db6f
+  data.tar.gz: b2221f7c2920cb7f5978f5ead9e3655a47fe464d6a738445f111e619736d6212f56d97e066d90000934878844c2a6b3937b58366eb086990987fc367b58d1649

data/CHANGELOG.md

@@ -1,3 +1,7 @@
+## [0.0.2] - 2024-06-20
+
+- Make sure content-type is json if we are json serializing an HTTP response
+
 ## [0.0.1] - 2024-05-31
 
 Very very alpha alpha release for convenience of demoing the project.

data/projects/command/src/concerns/reflection.rb

@@ -7,7 +7,7 @@ module Foobara
 
         def initialize(...)
           self.class.all << self
-          super(...)
+          super
         end
 
         module ClassMethods

data/projects/command_connectors_http/src/http/response.rb

@@ -4,9 +4,9 @@ module Foobara
       class Response < CommandConnectors::Response
         attr_accessor :headers
 
-        def initialize(headers:, **opts)
+        def initialize(headers:, **)
           self.headers = headers
-          super(**opts)
+          super(**)
         end
       end
     end

data/projects/command_connectors_http/src/http.rb

@@ -60,6 +60,15 @@ module Foobara
       def headers_for(request)
         response_headers = request.response_headers
 
+        if response_headers.nil? || !response_headers.key?("content-type")
+          if request.command.respond_to?(:serialize_result)
+            # TODO: we should ask the request this not the command.
+            if request.command.serializers.include?(Serializers::JsonSerializer)
+              response_headers = (response_headers || {}).merge("content-type" => "application/json")
+            end
+          end
+        end
+
         if response_headers
           static_headers.merge(response_headers)
         else

data/projects/manifest/src/foobara/manifest/type.rb

@@ -6,7 +6,7 @@ module Foobara
 
       class << self
         def new(root_manifest, path)
-          type = super(root_manifest, path)
+          type = super
 
           if self == Type
             if type.entity?

data/projects/manifest/src/foobara/manifest/type_declaration.rb

@@ -7,7 +7,7 @@ module Foobara
 
       class << self
         def new(root_manifest, path)
-          type_declaration = super(root_manifest, path)
+          type_declaration = super
 
           if self == TypeDeclaration
             case type_declaration.type.to_sym

data/projects/type_declarations/src/type_declaration_handler.rb

@@ -94,7 +94,7 @@ module Foobara
 
       def process_value(raw_type_declaration)
         # TODO: deep_dup this again??
-        super(raw_type_declaration).tap do |type_outcome|
+        super.tap do |type_outcome|
           if type_outcome.success?
             type_outcome.result.raw_declaration_data = raw_type_declaration
           end

data/projects/types/src/type.rb

@@ -35,7 +35,7 @@ module Foobara
       attr_reader :type_symbol
 
       def initialize(
-        *args,
+        *,
         target_classes:,
         base_type:,
         description: nil,
@@ -63,7 +63,7 @@ module Foobara
         self.name = name
         self.target_classes = Util.array(target_classes)
 
-        super(*args, **opts.merge(processors:, prioritize: false))
+        super(*, **opts.merge(processors:, prioritize: false))
 
         validate_processors!
       end

data/projects/value/src/processor/casting.rb

@@ -39,7 +39,7 @@ module Foobara
 
         attr_accessor :target_classes
 
-        def initialize(*args, casters:, target_classes: nil)
+        def initialize(*, casters:, target_classes: nil)
           self.target_classes = Util.array(target_classes)
 
           processors = [
@@ -47,7 +47,7 @@ module Foobara
             *casters
           ]
 
-          super(*args, processors:)
+          super(*, processors:)
         end
 
         def needs_cast?(value)

data/projects/value/src/processor/multi.rb

@@ -10,10 +10,10 @@ module Foobara
           end
         end
 
-        def initialize(*args, processors: [], prioritize: true)
+        def initialize(*, processors: [], prioritize: true)
           self.prioritize = prioritize
           self.processors = prioritize ? processors.sort_by(&:priority) : processors
-          super(*args)
+          super(*)
         end
 
         def processor_names

data/projects/value/src/processor/selection.rb

@@ -18,9 +18,9 @@ module Foobara
 
         attr_accessor :enforce_unique
 
-        def initialize(*args, enforce_unique: true, **opts)
+        def initialize(*, enforce_unique: true, **)
           self.enforce_unique = enforce_unique
-          super(*args, **opts)
+          super(*, **)
         end
 
         # TODO: move applies_message usage here from casting processor

data/projects/version/src/version.rb

@@ -1,5 +1,5 @@
 module Foobara
   module Version
-    VERSION = "0.0.1".freeze
+    VERSION = "0.0.2".freeze
   end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: foobara
 version: !ruby/object:Gem::Version
-  version: 0.0.1
+  version: 0.0.2
 platform: ruby
 authors:
 - Miles Georgi
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2024-05-31 00:00:00.000000000 Z
+date: 2024-06-21 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: foobara-util
@@ -32,17 +32,10 @@ executables: []
 extensions: []
 extra_rdoc_files: []
 files:
-- ".rspec"
-- ".rubocop.yml"
-- ".ruby-version"
 - CHANGELOG.md
-- DECISION_LOG.md
-- Guardfile
 - LICENSE-AGPL.txt
 - LICENSE.txt
 - README.md
-- Rakefile
-- concepts.md
 - projects/builtin_types/lib/foobara/builtin_types.rb
 - projects/builtin_types/src/README.md
 - projects/builtin_types/src/array/casters/arrayable.rb

data/.rspec

@@ -1,5 +0,0 @@
---format progress
---color
---require spec_helper
---order defined
---seed 0

data/.rubocop.yml

@@ -1,20 +0,0 @@
-AllCops:
-  TargetRubyVersion: 3.2
-  NewCops: enable
-
-inherit_gem:
-  foobara-rubocop-rules:
-    - rules/*
-
-Naming/FileName:
-  ExpectMatchingDefinition: true
-  CheckDefinitionPathHierarchy: true
-  Exclude:
-    - spec/lib/**/*
-    - spec/**/*
-    - bin/*
-  CheckDefinitionPathHierarchyRoots:
-    - src
-    - extensions
-    - spec
-  IgnoreExecutableScripts: true

data/.ruby-version

@@ -1 +0,0 @@
-3.2.2

data/DECISION_LOG.md

@@ -1,220 +0,0 @@
-This document is intended to document the rationale behind certain key decisions
-
-<!-- TOC -->
-* [2024-05-30 Dual-license under Apache-2.0 OR MIT](#2024-05-30-dual-license-under-apache-20-or-mit)
-  * [Decision](#decision)
-  * [Rationale](#rationale)
-    * [Why MIT](#why-mit)
-    * [Why Apache-2.0](#why-apache-20)
-    * [Why Apache-2.0 OR MIT](#why-apache-20-or-mit)
-    * [Other licenses that were contenders](#other-licenses-that-were-contenders)
-    * [Other concern about the murky state of generative AI and copyright implications](#other-concern-about-the-murky-state-of-generative-ai-and-copyright-implications)
-* [[RETRACTED] 2024-05-19 License under user choice of 3 licenses](#retracted-2024-05-19-license-under-user-choice-of-3-licenses)
-  * [Decision](#decision-1)
-  * [Rationale](#rationale-1)
-    * [Why MIT OR Apache 2.0](#why-mit-or-apache-20)
-      * [Why MIT is attractive](#why-mit-is-attractive)
-      * [Why Apache 2.0 is attractive](#why-apache-20-is-attractive)
-      * [Why MIT OR Apache 2.0 is attractive](#why-mit-or-apache-20-is-attractive)
-    * [Why OR MPL 2.0](#why-or-mpl-20)
-      * [why MPL 2.0 is attractive](#why-mpl-20-is-attractive)
-      * [Why OR MPL 2.0, ie, why is MPL 2.0 scary](#why-or-mpl-20-ie-why-is-mpl-20-scary)
-    * [What would have been an ideal license?](#what-would-have-been-an-ideal-license)
-  * [Conclusion](#conclusion)
-<!-- TOC -->
-
-# 2024-05-31 Temporarily release under AGPLv3
-
-## Decision
-
-Adopting a very restrictive license temporarily
-
-## Rationale
-
-Unblocks demos that benefit from use of rubygems while buying time to officially finalize a licensing decision.
-
-# [TENTATIVE] 2024-05-30 Dual-license under Apache-2.0 OR MIT
-
-## Decision
-
-Release gems in the foobara org under Apache-2.0 OR MIT.
-
-## Rationale
-
-### Why MIT
-
-* Typical license of the Ruby ecosystem
-* High-compatibility with other software licenses.
-
-### Why Apache-2.0
-
-* Robust
-* Includes patent grants
-
-### Why Apache-2.0 OR MIT
-
-* Maximizes contexts in which Foobara can unambiguously be used without
-  much overhead or confusion.
-* Reduces needs to debate less typical licensing options with users
-  or contributors.
-* Reduces need to relicense later for adoption's sake.
-* Just Apache-2.0 results in incompatibility with GPLv2
-* Just MIT does not explicitly extend patent grants.
-
-A thought... By choosing this combination instead of MPL-2.0, then it's not
-possible to use Foobara in a GPLv2 app without receiving a patent grant from the
-MIT license. However, my understanding is that such a user does at least know that
-all contributors have granted any patents in their contributed code to the Foobara
-project itself by meeting the requirements of both licenses in order to contribute.
-
-### Other licenses that were contenders
-
-* MPL-2.0
-  * Pros:
-    * Robust
-    * Compatible with GPLv2 and includes patent grants, eliminating the need to dual-license
-  * Cons:
-    * Not typical in the Ruby ecosystem and would result in conversations among contributors and users.
-    * Could also potentially impact adoption negatively though I don't think it logically should.
-  * Neutral:
-    * The copyleft aspects of MPL-2.0 seem fair while still being quite permissive. However, likely irrelevant because:
-      * These types of projects are typically used as unmodified libraries distributed by rubygems.
-      * When there is a modification, there's not much incentive not to share those improvements. It is
-        a hassle to manage a private fork and easier to just upstream improvements to avoid
-        that hassle.
-      * Even in the case of a private fork, typically the code winds up being used in some network service
-        and not "distributed" and so the copyleft is irrelevant in these common usage patterns
-    * File-level aspect.
-      * Receiving a copy of the modified code is generally the normal usage pattern since it's
-        an interpreted language. There are some tools for encoding but usually Ruby is interpreted from the source,
-        however, the typical pattern is to receive the code.
-        * Also means static-linking stuff is not relevant
-      * Ruby is so easy to monkey patch. It is very easy to modify a Ruby program without modifying a specific file.
-        Potentially undesirable to go down that path. Not sure. But, regardless, there are many ways to add
-        important code to a code base without disturbing certain files or at least minimally disturb them.
-        And, so, major improvements to code under the MPL can be made without technically triggering the copyleft
-        by leaving the old code in place and hooking new code into it.
-    * Makes it clear what license contributions are under (if using license headers in files.) This is because
-      1) modifications to existing files are MPL-2.0 via terms of the license, regardless of contributor intent.
-      2) new files can be force via the build to have license headers and therefore would express intent
-         by the contributor to license the code as MPL-2.0.
-
-      * Why irrelevant? Because github inbound=outbound convention means if the project is under X license
-        then a contribution is under X license by default.
-* OSL-3.0
-  * Pros
-    * This was the license I liked best of all the licenses I read. It felt quite fair and robust.
-  * Cons
-    * incompatible with not only GPLv2 but all GPL. So it's really dead-on-arrival.
-    * Is not popular and hasn't been defended in court.
-* EUPL and CDDL
-  * Based on MPL-1.1 and not compatible with GPLv2
-* LGPL
-  * Not very concise especially for an interpreted language.
-  * I'm worried about users incorrectly lumping it in with strong copyleft.
-  * I find it interesting that GNU recommends that you don't use LGPL.
-  * I think the philosophical/political views of the license authors on OSS are not really necessary
-    and I'm hesitant to make it seem like it's a position communicated by a community.
-
-### Other concern about the murky state of generative AI and copyright implications
-
-I would like similar code generated from AI trained on code from this project, or prompted with code
-from this project, to be considered a derived work.
-
-It doesn't seem like any of the existing popular licenses influence whether or not an AI-generated work
-is considered derived or not.
-
-# [RETRACTED] 2024-05-19 License under user choice of 3 licenses
-
-## Decision
-
-RETRACTED: kept in the history but should relocate these thoughts to some other resource.
-
-Release foobara gem (this repository) under the user's preference of
-3 different licenses: `MIT OR Apache 2.0 OR MPL 2.0` and come up with a shorter alias for this license.
-
-## Rationale
-
-### Why MIT OR Apache 2.0
-
-#### Why MIT is attractive
-
-MIT is attractive, aside from the obvious (permissible, simple), because this license
-is the typical license used in the Ruby community. Adoption would be as known-to-be-simple as possible under
-this license in this ecosystem.
-
-#### Why Apache 2.0 is attractive
-
-Apache 2.0 is attractive due to its robustness and extending patent permissions to users.
-
-#### Why MIT OR Apache 2.0 is attractive
-
-Dual-licensing under both allows the end-user to operate under either as-needed.
-
-The Rust community dual licenses under these two suggesting that a community can function under such
-a licensing scheme.
-
-Also, Bootstrap, in 2012, relicensed from Apache 2.0 to MIT so that GPLv2 projects could use Bootstrap.
-Dual licensing would have also been a solution but the point here is future-proofing unexpected pressure to
-relicense for adoption-sake.
-
-### Why OR MPL 2.0
-
-#### why MPL 2.0 is attractive
-
-MPL 2.0 seems to me (I am not an expert on this and far from it) after some research to be a robust license
-that seems to give nearly as much encouragement to give contributors back improvements to their
-original efforts without sacrificing much, if any, practical permissiveness.
-
-#### Why OR MPL 2.0, ie, why is MPL 2.0 scary
-
-It seems like there would be no serious practical burden imposed on users by the MPL 2.0 license. But I'm not
-100% certain of that without expert confirmation. And so, if users are also uncertain, that might hurt adoption
-even if in actuality the license is not a hassle to users in any meaningful way.
-
-What I mean by this is: if I have an MIT-licensed project, or a proprietary project, and I add a MPL-2.0 only gem
-to my .gemspec, is there any administrative burden imposed? It seems like "no" but again I am not an expert.
-If the answer is "no" but unclear to the user, that might still hurt adoption. To that extent, if confused with GPL
-style licenses, it might be ruled out by some organizations even if incorrectly so.
-
-However, making it OR MIT OR Apache 2.0 allows the user to just operate as if the project were licensed in
-the way most convenient to the user among those options, making adoption, I assume, at least as easy as MIT alone.
-
-But the real suspected benefit is this seems like it would allow MPL 2.0 to be the preferred license in the future
-without needing to seek relicense permission from contributors, nor CLAs to avoid seeking relicense permission.
-It is, in essence, a solution to punt and get back to coding for now and revisit with more real-world information
-later.
-
-### What would have been an ideal license?
-
-Hard to say without being an expert on licenses and user behavior but, at this time, my best (admittedly uninformed)
-guess would be to ideally use only one license, similar to MPL 2.0, but:
-
-1) without the file-level/static stuff as it is likely irrelevant for a gem like Foobara.
-2) with a network-exposure-is-distribution clause like AGPL 3.0, or really anything to maximize an
-   "if you improve it and make use of those improvements, then share the improvements" vibe, which,
-   with github and forks, seems like a trivial requirement to satisfy.
-3) if possible, a clause stating that code generated from Foobara code as
-   training data or prompt data to an AI system constitutes a derived work.
-
-Without expertise and given the point in history where I'm making this decision, I can't really draft
-such a license and even if I could that seems like it could be a bad strategy regardless (aka license proliferation)
-
-NOTE: if you happen to know an easy way for me to access expertise for clarity on these issues, please let me know.
-I'd be happy to pay for a short consult with a professional (ie lawyer who specializes in open-source licensing.)
-
-## Conclusion
-
-License under MIT OR Apache 2.0 OR MPL 2.0 for now to:
-
-1) guarantee seamless fit into Ruby ecosystem (MIT)
-2) extend patent-granting in case somebody wants that (Apache 2.0/MPL 2.0)
-3) allow future relicensing under MPL 2.0 without CLAs or non-trivial-contributor-roundup if it turns out that MPL 2.0
-   would have been a good choice once more is understood about the adoption-impact of having chosen that license.
-4) stop thinking about licensing and get back to hackin'
-
-To be clear, we are punting for now. At some point, we should choose either:
-
-1) MPL 2.0
-2) MIT OR Apache 2.0 (works for Rust community... seems there's no need to decide between these two)
-3) Some other better-fitting license (would require permission from non-trivial contributors)

data/Guardfile

@@ -1,9 +0,0 @@
-guard :rspec, all_after_pass: true, all_on_start: true, cmd: "bundle exec rspec", failed_mode: :focus do
-  watch(%r{^spec/(.+)_spec\.rb$})
-  watch(%r{^src/(.+)\.rb$}) { |m| "spec/#{m[1]}_spec.rb" }
-  watch(%r{^src/foobara/command/concerns/(.+)\.rb$}) { |_m| "spec/foobara/command_spec.rb" }
-  watch(%r{^lib/(.+)\.rb$}) { |m| "spec/lib/#{m[1]}_spec.rb" }
-  watch(%r{^spec/spec_helper.rb$}) { "spec/" }
-  watch(%r{^src/commands.rb$/}) { "spec/" }
-  watch(%r{^projects/([^/]+)/src/(.+)\.rb$}) { |m| "spec/foobara/#{m[1]}/#{m[2]}_spec.rb" }
-end

data/Rakefile

@@ -1,10 +0,0 @@
-require "bundler/gem_tasks"
-require "rspec/core/rake_task"
-
-RSpec::Core::RakeTask.new(:spec)
-
-require "rubocop/rake_task"
-
-RuboCop::RakeTask.new
-
-task default: %i[spec rubocop]

data/concepts.md

@@ -1,153 +0,0 @@
-<!-- TOC -->
-
-* [Command](#command)
-* [Type < Value::Processor](#type--valueprocessor)
-* [type declaration value](#type-declaration-value)
-* [Type reference](#type-reference)
-* [Domain](#domain)
-* [Organization](#organization)
-* [Domain mapper](#domain-mapper)
-* [Value::Processor](#valueprocessor)
-    * [Value::Caster < Value::Processor](#valuecaster--valueprocessor)
-    * [Value::Validator < Value::Processor](#valuevalidator--valueprocessor)
-    * [Value::Transformer < Value::Processor](#valuetransformer--valueprocessor)
-    * [Desugarizer < Value::Transformer](#desugarizer--valuetransformer)
-    * [TypeDeclarationValidator < Value::Validator](#typedeclarationvalidator--valuevalidator)
-        * [in general:](#in-general)
-        * [types and type declarations:](#types-and-type-declarations)
-
-<!-- TOC -->
-
-These are notes about some things conceptual.
-
-# Command
-
-* A command is an encapsulation of a high-level business operation and is intended to be the public
-  interface of a system or subsystem.
-
-# Type < Value::Processor
-
-A type is an instance of the Types::Type class.
-
-It (the instance) is a namespace.
-
-It is a Value::Processor
-
-* reflection
-    * can give a type declaration value (formal or informal/sugary or strict) for this type
-    * can give the list of possible errors that could result from processing a value of this type
-      and the types for their context schemas
-    * can answer what value processors are supported for values of this type
-    * can answer which value processors are automatically applied for values of this type
-* can serve as a base type for another type
-* can process a value of this type
-    * can answer if a value needs to be cast
-    * can answer if a value can be cast
-    * can cast a value into an value of this type
-    * can transform a value of this type
-    * can validate a value of this type
-* processor registry operations
-    * can register a supported value processor
-    * can register a value caster
-
-# type declaration value
-
-* Something that defines/declares a type in a declarative fashion.
-    * Can have a sugary form for human expression/readability/writability
-    * Is easily serializable for cross-system metaprogramming
-* example:
-  ```ruby
-  { 
-    foo: :integer,
-    bar: [:integer, :optional, :allow_blank, min: 1]
-  }
-  ```
-* In this example, we are using a sugary declaration to specify a new type of
-  attributes type that can represent a value like `{ foo: -20, bar: 10 }`
-
-# Type reference
-
-* References a "registered" type. A registered type has a type symbol and belongs to a domain.
-* An unresolved type reference doesn't have to be absolute and is looked up in the current
-  Foobara namespace.
-* A resolved type is absolute.
-* A type reference can be used as a type declaration.
-
-# Domain
-
-* A namespace for Commands and Types
-* can depend on other domains in a unidirectional way
-
-# Organization
-
-* namespace for collecting domains
-
-# Domain mapper
-
-* Translates models (or types or commands inputs/results) to models (or types or command inputs/results) in
-  another domain.
-
-# Value::Processor
-
-* Has a process_value method that receives a value and returns an Outcome
-* Can have an applicable?(value) method
-* Answers what errors are possible
-    * Including the type of their context
-
-## Value::Caster < Value::Processor
-
-* gives #cast instead of #transform but same idea, takes value returns value
-* like ValueProcessor, never gives errors
-* only one value caster per type should be #applicable? for a given value.
-    * Therefore doesn't have to play nicely with other Casters, unlike Transformers/Validators
-
-## Value::Validator < Value::Processor
-
-* gives #validation_errors that takes value and returns errors
-* never gives new value
-
-## Value::Transformer < Value::Processor
-
-* gives #transfomer that takes value and returns value
-* never gives errors
-
-## Desugarizer < Value::Transformer
-
-* takes sugary type declaration and returns strict type declaration
-
-## TypeDeclarationValidator < Value::Validator
-
-* Validates type declarations
-
-A way to think about the interfaces/concepts involved here, if helpful:
-
-### in general:
-
-* Processor, Multi, Selection, Pipeline: value -> outcome
-* Multi < Processor: value -> outcome
-* Selection < Multi (chooses 1 processor among many to run): value -> outcome
-* Pipeline < Multi (chains a collection of processors together): value -> outcome
-* Processor, Multi, Selection, Pipeline: value -> outcome
-* Transformer: value -> value
-* Validator: value -> error[]
-
-Maybe not helpful, but, you could think of Processor/Multi/Selection/Pipeline as monads
-and Validator and Transformer as monads but with convenience methods that make assumptions
-about the context (transformer assumes there are no errors and validator assumes
-no transformation of the value.)
-
-### types and type declarations:
-
-* TypeDeclarationHandler: type declaration -> Type instance
-* TypeDeclarationHandlerRegistry: type declaration -> outcome<TypeDeclarationHandler>
-* Desugarizer: type declaration -> strict(er) type declaration
-* TypeDeclarationValidator: strict type declaration -> error[]
-* Type instance: value -> outcome
-* Type casting (is a Value::Pipeline of casters): value -> value
-* Caster: value -> value
-* Type transformers: value -> value
-* Type validators: value -> error[]
-* Type processors: value -> outcome
-* Supported type processors: value -> outcome
-* Supported type transformers: value -> value
-* Supported type validators: value -> error[]